AMD: updates voor OpenGL en DirectX liggen in lijn met Mantle-visie

AMD laat weten dat het bedrijf "graag de aangekondigde updates voor OpenGL en de DirectX-api's tegemoet ziet." Die gaan vergelijkbare functionaliteit als Mantle bieden, zo bleek deze week, maar volgens AMD duurt dat nog wel even.

De verklaring is door AMD gegeven aan de website TechReport. Het bedrijf reageert op het nieuws dat DirectX en OpenGL wellicht updates krijgen die ontwikkelaars meer controle geven over grafische hardware. Deze updates zouden de belasting op cpu's moeten verminderen en prestaties van videokaarten verbeteren op een vergelijkbare manier als AMD Mantle dat nu doet bij bijvoorbeeld Battlefield 4. Mantle zou ook naar de nieuwe Thief-game komen, maar die ondersteuning is uitgesteld tot maart.

Het nieuws dat OpenGL en DirectX het voorbeeld van Mantle volgen, blijkt uit een aantal korte samenvattingen die op de website van de Game Developers Conference 2014 staan. Microsoft heeft twee bijeenkomsten gepland die in het oog springen. Een daarvan draagt de titel 'DirectX: Evolving Microsoft's Graphics Platform'. In de samenvatting spreekt Microsoft van "beter gereedschap om het allerlaatste beetje prestaties uit je pc, tablet, telefoon en console te persen." Microsoft gebruikt in de tekst ook de term 'closer to the metal'; een aanduiding die AMD in het verleden ook al voor Mantle heeft gebruikt. Daarnaast heeft Microsoft een presentatie getiteld 'DirectX: Direct3D Futures', waar ze vertellen over "toekomstige verbeteringen aan Direct3D die ontwikkelaars een weergaloze hoeveelheid toegang en controle geven over hardware en die cpu-belasting terugdringt bij een breed ecosysteem aan hardware."

De mensen achter OpenGL hebben ook een bijeenkomst voorbereid over het onderwerp. Bij 'Approaching Zero Driver Overhead in OpenGL' vertellen mensen van Nvidia, Intel en AMD over "concepten die overhead van de driver met een factor tien of meer verlagen." De Game Developers Conference in San Francisco begint op 17 maart en duurt tot en met 21 maart. De presentaties over DirectX en OpenGL vinden plaats op 20 maart.

Reacties (138)

[BlaDeKke]

Dit is zo'n IE6 situatie. Oei concurrentie, we moeten terug aan het werk...

Link naar een artikel waar microsoft weeral belooft zijn aandacht op het PC gamen te richten. Vooral de eerste reactie is fenomenaal maar te lang om hier te posten.

[Reactie gewijzigd door BlaDeKke op 24 juli 2024 15:26]

[Verwijderd]

Niet helemaal terecht vind ik..
IE6 was gewoon complete bagger en dat kan je van Direct3D niet zeggen.

Ontwikkelaars zijn al een tijdlang over Direct3D en dan met name de SDK die microsoft te bieden heeft unaniem positief. (waaronder Carmack)
Dat was in de dagen van weleer m.b.t. Direct3D wel anders. Destijds is er zelfs een petitie geweest onder ontwikkelaars waarmee men de ongenoegen over D3D wilde uiten. (waaronder Carmack)

De keuze voor D3D is vandaag de dag niet alleen eentje van monopolie, het is ook daadwerkelijk een goede API.
Dit is vooral een " markt reactie " van Microsoft. En, toegegeven, dat doen ze iets te vaak zonder resultaten te leveren.

Overigens is mantle " voorzichtig positief" ontvangen, het is niet de revolutie die sommigen hadden gehoopt dat het zou zijn.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[BlaDeKke]

Het is een goede API, maar wordt er nog serieus aan doorgewerkt?

Het is toch in het voordeel van Microsoft D3D nu wat te laten liggen aangezien de Xbox One er nu is en nog jaren gaat moeten meegaan. De hardware van onze PC's is klaar voor een volgende stap maar dat kunnen de consoles niet aan, tenzij ze binnen een jaar met de PS5 en XBOX Two uitkomen.

En ze gaan het niet graag zien gebeuren dat de PC's 10x mooier beeld op het scherm toveren dan de laatste nieuwe super duper next gen consoles...

Microsoft heeft destijds de tablet markt onder druk willen zetten met de Surface.
AMD nu met Mantle?

Dit is mijn visie op de zaak, ik kan er ook compleet naast zijn. Please prove me wrong.

[Verwijderd]

Het is een goede API, maar wordt er nog serieus aan doorgewerkt?

Ja.
Zoals ik al zei: Microsoft ontwikkelt D3D wel degelijk door. Windows 7 kwam met D3D11. Windows 8 met D3D11.1, en Windows 8.1 met D3D11.2. Nogal frappant dat veel mensen net doen alsof MS jarenlang heeft stilgezeten met D3D.

Het is toch in het voordeel van Microsoft D3D nu wat te laten liggen aangezien de Xbox One er nu is en nog jaren gaat moeten meegaan.

Hoezo? De vorige XBox was gebaseerd op D3D9, en men heeft vrij kort na de introductie al D3D10 gelanceerd, en daarna nog D3D11.

En ze gaan het niet graag zien gebeuren dat de PC's 10x mooier beeld op het scherm toveren dan de laatste nieuwe super duper next gen consoles...

Dat doen ze nu toch al. De XBox kan veel games niet eens in native 1080p draaien. Een beetje gaming-PC kan makkelijk hogere resoluties draaien, en dan ook nog eens met meer AA en meer detail etc.
Daar heb je niet per se een nieuwe API voor nodig.

[sharkwouter]

Wel jammer dat er iedere keer als er een nieuwe versie van DirectX uitkomt een nieuwe versie van Windows nodig is, terwijl de vorige versie nog ondersteunt wordt. De rede dat Halo al jaren niet meer naar de pc komt is omdat de verkoop van Halo 2 voor de pc tegenviel, volgens Microsoft. Daar vermelden ze niet bij dat je er Windows Vista voor nodig had, waar niemand op zat te wachten.

[Verwijderd]

Wel jammer dat er iedere keer als er een nieuwe versie van DirectX uitkomt een nieuwe versie van Windows nodig is, terwijl de vorige versie nog ondersteunt wordt.

Dat is niet helemaal waar. Historisch gezien is het eerder regel dat iedere versie van Windows wel een D3D-update krijgt. XP begon met D3D8.1, en kreeg D3D9. D3D11 is ook naar Vista gekomen. D3D11.1 wordt ook deels ondersteund op Windows 7.
Omdat D3D11.1 en 11.2 slechts uitbreidingen op D3D11 zijn, kun je nog wel 1 codebase maken, waarbij je optioneel de nieuwe functies gebruikt op Windows 8.x.

[koelpasta]

"Dat doen ze nu toch al. De XBox kan veel games niet eens in native 1080p draaien. Een beetje gaming-PC kan makkelijk hogere resoluties draaien, en dan ook nog eens met meer AA en meer detail etc.
Daar heb je niet per se een nieuwe API voor nodig. "

Nee, maar resolutie en aa vind ik nou niet echt de definitie van een mooier beeld. Sterker nog, de meeste games geven een mooier beeld als je ze op een lagere resolutie speelt, puur omdat het nivo van de details in de textures en geometrie dan beter overeenkomen met het beeld en elke pixel dan beter gevuld is.

[Verwijderd]

Nee, maar resolutie en aa vind ik nou niet echt de definitie van een mooier beeld. Sterker nog, de meeste games geven een mooier beeld als je ze op een lagere resolutie speelt, puur omdat het nivo van de details in de textures en geometrie dan beter overeenkomen met het beeld en elke pixel dan beter gevuld is.

Dat verandert het verhaal verder niet. Ook voor meer gedetailleerde textures en geometrie heb je geen nieuwe API voor nodig. Alleen snellere hardware. En die hebben we dus al.

[koelpasta]

Nee, en dat is juist het punt.
Mantle is bedacht om meer verschillende dingen in het beeld te kunnen doen door de communicatie van de cpu naar de gpu korter te maken.
Hierdoor kun je per frame meer commando's aan de gpu geven. Ook kan je de gpu beter aan het werk zetten. De gpu wordt dan minder afhankelijk van commando's van de cpu en hoeft dan minder te wachten op het tijdsslot van die communicatie maar kan op de achtergrond alvast aan de slag. Zo wordt o.a. gpu memory geexposed waardoor je shaders niet meer afhankelijk zijn van beschikbare data.

Bij een hogere resolutie teken je eigenlijk precies hetzelfde als bij een lage alleen uitgerekt over een groter oppervlak. Dat noem ik geen verbetering van het beeld. Wat echt interessant is is dat er meer verschillende dingen in beeld te zien zijn. En dan speelt resolutie niet zoveel mee.
Vandaar dat een hogere resolutie niet betekent dat het beeld er beter van wordt.

Het rare is dat jij dit zou moeten begrijpen als dx programmeur.
Nooit tegen een draw call limiet gezeten, bijvoorbeeld?

[Verwijderd]

Zo wordt o.a. gpu memory geexposed waardoor je shaders niet meer afhankelijk zijn van beschikbare data.

Uhh, begrijp je zelf wel wat je hier zegt? Kun je dit eens wat beter uitleggen?

Het rare is dat jij dit zou moeten begrijpen als dx programmeur.
Nooit tegen een draw call limiet gezeten, bijvoorbeeld?

Er zijn genoeg manieren om daaromheen te programmeren.

[koelpasta]

"Uhh, begrijp je zelf wel wat je hier zegt? Kun je dit eens wat beter uitleggen?"

Shaders kunnen pointen naar willekeurig vram alleen probeert de api aan de CPU kant normaal gesproken die data synchroon te houden. De CPU wil dus ten aller tijde zeker weten met welke data de gpu aan de slag gaat en gedraagt zich in deze setup als een master controler. Vandaar dat de bestaande apis zo'n strict communicatieschema hebben met nauwkeurig gestructureerde data om performance mogelijk te maken. Dat is op zich helemaal niet nodig en vandaar dat ze bijvoorbeeld die asynchrone buffers hebben uitgevonden. Maar dat is eigenlijk een api hack met beperkte functionaliteit op een gpu feature waar je eigenijk veel flexibeler mee om zou kunnen gaan. Er is lang niet altijd een goede reden om die data strict gecontroleerd vanuit de api te houden. Voor de GPU is het alleen maar een domme pointer naar wat geheugen en die is dus agnostisch over wat er in dat geheugen staat. Maar de API's dicteren vanalles en nogwat over hoe en wanneer je met die buffers om moet gaan.
Dat geeft enorm veel richting maar het is niet altijd de richting die een engine coder op wil gaan.
Eigenlijk willen we dat de gpu meer een master rol in het geheel krijgt en de cpu meer een data server wordt, in ieder geval als het op renderen aankomt.
Hier bieden zowel OGL als DX weinig faciliteiten voor.


"Er zijn genoeg manieren om daaromheen te programmeren. "

En het feit dat je daaromheen moet programmeren betekent dat het een slecht passende oplossing is. Lijkt me vrij duidelijk. Er zou nul reden moeten zijn om om de beperkingen van een grafische api om te moeten programmeren maar zowel OGL als DX hebben problemen waardoor het alsnog nodig is om om de bedachte architectuur om te werken om maximale performance en controle te verkrijgen.
En vandaar dat je allerlei zaken ziet uitbulken in die apis om de nieuwe mogelijkheden alsnog te kunnen opnemen.
Specifieke buffers, specifieke calls voor die buffers, etc etc.,

[Verwijderd]

Shaders kunnen pointen naar willekeurig vram alleen probeert de api aan de CPU kant normaal gesproken die data synchroon te houden. De CPU wil dus ten aller tijde zeker weten met welke data de gpu aan de slag gaat en gedraagt zich in deze setup als een master controler.

Okee, je snapt het dus niet.
De API maakt alleen stukken geheugen aan in de driver (dat kan direct in videogeheugen zijn, danwel in systeemgeheugen, afhankelijk van wat je specificeert), en die kun je mappen naar de CPU om ze te vullen.
Verder valt er niets 'synchroon' te houden. Weet niet waar je dat vandaan haalt.
Wederom klopt er daarom helemaal niets van de rest van je verhaal.
Hoog klok-en-klepel-gehalte.

En het feit dat je daaromheen moet programmeren betekent dat het een slecht passende oplossing is. Lijkt me vrij duidelijk.

Ben ik het niet mee eens.
Het is net als programmeren in het algemeen:
Je kunt wel een slecht algoritme met de hand op instructieniveau optimaliseren, maar het blijft een slecht algoritme.
Een efficienter algoritme zal ook in een iets minder geoptimaliseerde implementatie al veel sneller zijn.

Verder kun je maar beter stoppen met praten over buffers etc, want je weet niet waar je het over hebt, met alle respect.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[Countess]

Zoals ik al zei: Microsoft ontwikkelt D3D wel degelijk door. Windows 7 kwam met D3D11. Windows 8 met D3D11.1, en Windows 8.1 met D3D11.2. Nogal frappant dat veel mensen net doen alsof MS jarenlang heeft stilgezeten met D3D.

die versies zijn leuk, maar voornamelijk gerommel in de marges.

het is niet wat directX nodig heeft, en dat is een enorme afslanking in wat het allemaal (grotendeels onnodig tegenwoordig) doet.

[Verwijderd]

het is niet wat directX nodig heeft, en dat is een enorme afslanking in wat het allemaal (grotendeels onnodig tegenwoordig) doet.

Weet je wel waar je het over hebt?
In D3D11.1 had je oa grote constant-buffers met subranges: http://msdn.microsoft.com...op/hh404562(v=vs.85).aspx
Hierdoor kun je efficienter (als in: minder CPU-overhead) constants doorgeven aan de GPU.
In D3D11.2 heb je tiled resources, waardoor het in- en uitswappen van textures voor bv terrein een stuk efficienter kan (wederom: minder CPU-overhead): http://msdn.microsoft.com...op/dn312084(v=vs.85).aspx

Gerommel in de marges? Niet bepaald.

[Verwijderd]

Tja het is alleen jammer dat ze nu D3D baseren op de windows versie...
sommige mensen willen gewoon niet aan windows 8 beginnen.

[Verwijderd]

Dat was in de dagen van weleer m.b.t. Direct3D wel anders. Destijds is er zelfs een petitie geweest onder ontwikkelaars waarmee men de ongenoegen over D3D wilde uiten. (waaronder Carmack)

De ironie is dat men destijds Direct3D te low-level vond. De eerste versies van D3D werkten met 'execute buffers', waarbij je direct opcodes en data in een buffer moest zetten, die aan de driver doorgegeven werd.
Dat vond Carmack te moeilijk, en hij gebruikte liever OpenGL, wat veel meer high-level was.

Microsoft heeft toen ook een meer OpenGL-achtige high-level API geintroduceerd.
De grap is nu dus dat de tendens ineens omslaat en men nu WEL low-level APIs wil. En zowel D3D11 als Mantle geven de ontwikkelaar nu dus weer meer controle over die execute buffers (ook wel pushbuffers genoemd) in de driver. Vooral voor multithreading is het namelijk handig om meerdere buffers tegelijk te kunnen bewerken en klaar te zetten (wat dus met de eerste versie van D3D wel gekund had).
D3D11 heeft daar dus Driver Command Lists voor: http://msdn.microsoft.com...op/ff476885(v=vs.85).aspx

Op consoles doet men ook nog andere trucjes met dergelijke buffers (bv alleen een paar commando's aanpassen voor een buffer van een heel frame, zodat niet steeds een hele nieuwe buffer gemaakt hoeft te worden).

Dus had MS achteraf met de eerste versie van D3D wel gelijk gehad?

[koelpasta]

"Op consoles doet men ook nog andere trucjes met dergelijke buffers (bv alleen een paar commando's aanpassen voor een buffer van een heel frame, zodat niet steeds een hele nieuwe buffer gemaakt hoeft te worden)."

Het hele idee van die buffers is best wel legacy.
Die zijn er alleen bedacht om een stuk overdracht te formaliseren maar bestaan op de gpu niet maar worden door de driver, die een common ground moet leveren voor verschillende APIs, afgebroken en aan de gpu gevoerd. Zeker nu er steeds vaker meerdere renderpasses per frame worden gedaan worden de beperkingen van deze abstractie steeds gebrekkiger en raken de api's bloated met uitzonderingen. Je zou theoretisch een heel andere abstractie kunnnen gebruiken die overzichtelijker en efficienter is dan al die varianten op buffer objecten. In princiepe is een gpu redelijk agnostisch over waar ie zn data vandaan haalt en wanneer dus de noodzaak voor al die uitzonderingen gespecificeerd in de api's wordt minder.
Vandaar dat een nieuwe api best wel op zn plek is.

[Verwijderd]

Het hele idee van die buffers is best wel legacy.
Die zijn er alleen bedacht om een stuk overdracht te formaliseren maar bestaan op de gpu niet maar worden door de driver, die een common ground moet leveren voor verschillende APIs, afgebroken en aan de gpu gevoerd.

We hebben het hier over consoles, daar heb je helemaal geen drivers en verschillende APIs. De pushbuffers op een console zijn gewoon letterlijk de native instructies voor de GPU.
Die buffers zijn NOOIT 'legacy' natuurlijk. Wat voor GPU je ook hebt, je moet altijd een buffer met instructies ernaartoe sturen. Net als dat ook met CPUs altijd al gebeurt.

Bij D3D/OGL wil je iets meer abstractie, maar het is wel zo dat een abstracte buffer eenmalig door de driver naar een native buffer vertaald kan worden (eventueel op een aparte thread), en dat die native buffer dan direct aan de GPU gestuurd kan worden, eventueel meerdere keren. Dat kan met D3D11 dus al een paar jaar.

Vandaar dat een nieuwe api best wel op zn plek is.

Als jij de pushbuffers van een console al 'legacy' wil noemen, denk ik niet dat jij er genoeg van begrijpt om zoiets te kunnen beoordelen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[koelpasta]

"Die buffers zijn NOOIT 'legacy' natuurlijk. Wat voor GPU je ook hebt, je moet altijd een buffer met instructies ernaartoe sturen. Net als dat ook met CPUs altijd al gebeurt."

Niet het feit dat er geheugen nodig is maakt het legacy.
Het feit dat je met dit soort buffers veel meer kan dan wat de apis aanbieden maakt dat die implementaties legacy zijn.
Vandaar dus dat ze telkens een net iets ander code pad vereisen om het een en ander mogelijk te maken. Dan blijk je ergens een ander type buffer te moetten hebben gebruikt anders kom je verderop in de knoei met feature x of y.

"Bij D3D/OGL wil je iets meer abstractie, maar het is wel zo dat een abstracte buffer eenmalig door de driver naar een native buffer vertaald kan worden (eventueel op een aparte thread), en dat die native buffer dan direct aan de GPU gestuurd kan worden, eventueel meerdere keren. "

Maar dan is die data nog niet eens op de GPU aangekomen.
Veel beter wordt het als de GPU zelf 'native buffers' (voor een gpu dus gewoon een pointer naar wat geheugen) gaat samenstellen op basis van wat data-arme commando's vanuit de api.
En dat is op zn minst omslachtig door de overlay van datastructuren door de api's (alle zooi die de api's afdwingen op een gpu, via drivers, om het ding in lijn te brengen met de verwachtingen van de api) .

[Verwijderd]

Vandaar dus dat ze telkens een net iets ander code pad vereisen om het een en ander mogelijk te maken. Dan blijk je ergens een ander type buffer te moetten hebben gebruikt anders kom je verderop in de knoei met feature x of y.

Je begrijpt dus niet wat een 'pushbuffer' of 'execute buffer' is. Zoals ik al zei, dat is een buffer met GPU-instructies. Jij lijkt dat te verwarren met andere buffers als textures, constant buffers, vertex buffers etc.
Daarom klopt de rest van je verhaal dus ook niet.

[Verwijderd]

Dit is zo'n IE6 situatie. Oei concurrentie, we moeten terug aan het werk...

Heeft eerder te maken met de hardware van consumenten die ondersteund moet worden. D3D11 kan nog gewoon draaien op DX9-klasse hardware (ook smartphones dus). Met Mantle heeft AMD meteen rigoreus gebroken met oudere hardware, en alleen de nieuwste DX11-kaarten worden ondersteund (dus ook niet de oudere DX11-kaarten).
Zo'n stap kan Microsoft niet zomaar even maken. Toen ze dat met D3D10 deden, kwam ze dat ook op veel kritiek te staan.

Microsoft ontwikkelt D3D wel degelijk door. Windows 7 kwam met D3D11. Windows 8 met D3D11.1, en Windows 8.1 met D3D11.2. Nogal frappant dat veel mensen net doen alsof MS jarenlang heeft stilgezeten met D3D.

[Countess]

de legacy ondersteuning en opzet gaat echter nog veel verder terug dan dx9.

toen dx werd ontwikkelend was de PC graphics markt heel anders als nu het geval is. veel van de dingen die toen nodig waren zijn helemaal niet meer van toepassing vandaag omdat de GPU's van alle fabrikanten zo veel op elkaar lijken. maar al die dingen zitter er nog steeds en en worden nog steeds door de DirectX uitgevoerd op de CPU.

microsoft heeft nooit een keer echt de schop in directX gezet, en heeft enkel nieuwe features/shaders toegevoegd.

[Verwijderd]

de legacy ondersteuning en opzet gaat echter nog veel verder terug dan dx9.

Oh god, kom je weer met dat argument.
Ik heb het al eerder geprobeerd uit te leggen, maar je weet niets van wat een API is, dus is dat een onmogelijke taak...
D3D11 heeft z'n eigen set objecten met hun eigen interfaces (http://msdn.microsoft.com...op/ff476154(v=vs.85).aspx). Deze staan compleet los van eerdere versies. Alle major updates van D3D hebben zo hun eigen interfaces, die allemaal naast elkaar bestaan.
De interfaces van D3D9 (http://msdn.microsoft.com...op/ff471470(v=vs.85).aspx) lijken TOTAAL niet op die van D3D10 of 11.
Ook het onderliggende drivermodel is voor D3D10 dus compleet op de schop gegaan (vandaar minimaal Vista nodig), en ook dat lijkt dus niet op wat men met D3D9 gebruikte.

microsoft heeft nooit een keer echt de schop in directX gezet, en heeft enkel nieuwe features/shaders toegevoegd.

Dat hebben ze zo vaak gedaan. Jij snapt het alleen niet.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[Countess]

Dat hebben ze zo vaak gedaan. Jij snapt het alleen niet.

en toch doen ze nog zo veel te veel dat directX enorm langzaam kan zijn terwijl dat niet nodig is. en blijkbaar is microsoft het met me eens wat nu ineens gaan we er wel werk van maken.

[Verwijderd]

en toch doen ze nog zo veel te veel dat directX enorm langzaam kan zijn terwijl dat niet nodig is.

'Niet nodig' is zeer subjectief. Voor de doelstellingen van D3D is het wel nodig.

en blijkbaar is microsoft het met me eens wat nu ineens gaan we er wel werk van maken.

Niet 'nu ineens'. Microsoft heeft gedurende de hele geschiedenis van D3D een hoop updates gedaan om de API goed op de hardware aan te laten sluiten. Veel meer dan OpenGL.
D3D10 stond compleet in het teken van het verwijderen van de legacy, en het verlagen van de CPU-overhead door het aantal calls drastisch te verlagen.
D3D11 voegde hier verbeterde multithreading-support aan toe.
Dit is gewoon de zoveelste stap in de ontwikkeling van D3D.

[Countess]

en toch verslaat mantle DirectX11 nog steeds met gemak, en dat ZONDER vender specifieke functies.

[Countess]

zoals al gezegt dat directX dus veel langzamer is als nodig is. dat ze het niet voor elkaar krijgen (of niet de durf hebben) om ook echt een keer de schop er in te zetten.

[Verwijderd]

zoals al gezegt dat directX dus veel langzamer is als nodig is.

Dan heb je blijkbaar niet begrepen wat ik zei: Wat nodig is, wordt bepaald door de doelstellingen van een API.
Mantle en D3D11 hebben niet dezelfde doelstellingen.

dat ze het niet voor elkaar krijgen (of niet de durf hebben) om ook echt een keer de schop er in te zetten.

Man, als je toch eens wist waar je het over had!
Toen D3D10 uitkwam, renden veel ontwikkelaars gillend weg, omdat het in de verste verte niet leek op D3D9. Ze moesten hun engine-ontwerp compleet opnieuw uitdenken en alles van voren af aan opnieuw ontwikkelen.
Microsoft durft echt wel, je hebt geen idee!

[koelpasta]

"Dan heb je blijkbaar niet begrepen wat ik zei: Wat nodig is, wordt bepaald door de doelstellingen van een API.
Mantle en D3D11 hebben niet dezelfde doelstellingen."

Ja, en de doelstelling van microsoft lijkt gaming op de pc enigzins in de weg te staan. Anders was er geen winst te halen voor mantle.

Sinds microsoft een eigen gameconsole heeft wordt het steeds minder belangrijk voor ze om gaming op de pc te ondersteunen. Sterker nog, de pc is een grote concurent van de xbox omdat ze op de xbox veel meer aan media verdienen. et is voor microsoft een doel om pc gamers over te halen hun games op de xbox te consumeren.
Je hoeft alleen te kijken naar initiatieven als 'games for windows' om te zien hoe microsoft werkelijk over pc gaming denkt.
Dat werdt ooit aangekondigd als de redding van het pc platform maar in al die tijd (sinds 2006) zijn de meeste games die ik op de pc heb gespeeld niet uit de 'games for windows' kast.
PC gaming op strategisch nivo bij microsoft is huilen met de pet op.

[Verwijderd]

Ja, en de doelstelling van microsoft lijkt gaming op de pc enigzins in de weg te staan. Anders was er geen winst te halen voor mantle.

Typisch gevalletje van low-hanging fruit. Er is *wat* winst te halen omdat:
A. De D3D11-drivers van AMD niet bepaald uitblinken in het ondersteunen van multithreading (nVidia scoort veel beter in D3D in CPU-limited situaties, zelfs in BF4: http://techreport.com/rev...rmance-in-battlefield-4/2)
B. Een nieuwe versie van D3D gaat gepaard met meer 'red tape', omdat MS en alle IHVs het eens moeten worden, en er dan een geschikt moment moet komen voor de release van de nieuwe versie van D3D (bv een nieuwe generatie hardware, of een nieuwe versie van Windows). MS kan niet voor iedere zucht een API-update uitgeven.

Wat je dus ziet is een heel gekleurd beeld (wat nog versterkt wordt omdat review sites massaal verzuimen om de CPU-overhead te testen van OGL/D3D in verschillende games met verschillende hardware).

Sinds microsoft een eigen gameconsole heeft wordt het steeds minder belangrijk voor ze om gaming op de pc te ondersteunen.

Zo eenvoudig ligt het niet. Naast D3D is er ook nog OGL. Als D3D niet meer voldoet, dan stappen developers wel massaal over op OGL, want OGL kan onafhankelijk van MS doorontwikkeld worden (desnoods op andere OSen dan Windows).
Maar D3D blijft voorlopen op OGL, dus kennelijk is er geen sprake van dat MS de zaken te veel loopt af te remmen.

PC gaming op strategisch nivo bij microsoft is huilen met de pet op.

En dus? Er zijn genoeg andere ontwikkelaars. Beetje raar als je "Games for Windows" gelijkstelt met alle games op het Windows-platform.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[Relief2009]

Je denkt toch niet dat MS pas sinds AMD's Mantle introduceerde is begonnen met ontwikkelen. Je vergeet dat MS al heel lang een aangepaste DirectX met on the metal api's aanbiedt voor de xbox. Ze doen niets anders dan deze naar de PC brengen.

Aan de andere kant het heeft niets te maken met achterlopen. AMD kan Mantle maken omdat het alleen hun eigen (nieuwste) hardware ondersteund. Microsoft moet meerdere merken ondersteunen (AMD, Nvidia, Intel).

Maar goed zeiken op MS is o zo makkelijk. En oh ja, welke concurrentie? AMD is nog steeds afhankelijk van MS voor zowel consoles als games.

[Reactie gewijzigd door Relief2009 op 24 juli 2024 15:26]

[dipje2]

Andere vraag, Mantle is door AMD voor AMD. En dan zelfs specifiek GCN, dus als game ontwikkelaar 'die dicht bij de hardware programmeert' weet je over wat voor soort kaarten het gaat.

Als 'DirectX' dichter bij de hardware wil.. is het zorgen dat het werkt op meerdere generaties en merken van chips dan de zorg voor DirectX of komt dat opeens bij de game ontwikkelaar te liggen?. Want dat laatste geeft me weinig hoop voor de resultaten.

Alhoewel, terwijl ik dit tik... Als een game-ontwikkelaar dus een code-path voor een bepaalde chipset heeft om minder overhead en meer efficientie te krijgen, kan er nog altijd op 'ouderwets Direct3D' worden terug gevallen voor generaties/chipsets die er dan buiten vallen natuurlijk. Zo zorg je tenminste dat het op z'n minst werkt.

Maar ga de wat meer onwetende consumenten maar eens uitleggen waarom een bepaalde kaart heel goed in een bepaalde game scoort maar voor geen meter in een andere. Of waarom hij toch een sterke CPU nodig heeft, want je zal maar net die game willen spelen die nog van 'ouderwets Direct3D' gebruik maakt en dus meer CPU power nodig heeft

Maar goed. Ik zie dus of in dat OpenGL/DirectX het generiek voor alle soorten hardware moeten houden, en dus nooit het niveau van 'op het metaal' zullen halen van Mantle... of ze ditchen de generieke aanpak en laten de support voor verschillende GPU chips over aan de game ontwikkelaars, waar ik weer een hoop 'segmentatie' en problemen en bugs zie verschijnen in de toekomst.

[Countess]

Mantle is door AMD voor AMD. En dan zelfs specifiek GCN

nee dat is het niet. Mantle is ontwikkeld om een open standaard te worden, waar intel en nVidia ook gebruik van kunnen maken.

de planning is een release als open standaard eind dit jaar.

[Verwijderd]

Mantle is ontwikkeld om een open standaard te worden, waar intel en nVidia ook gebruik van kunnen maken.

En je denkt nog steeds dat ze dat gaan doen? Deze updates aan OpenGL komen grotendeels uit de koker van nVidia zelf.
Waarom zouden Intel en nVidia Mantle gaan ondersteunen als je met OpenGL en D3D vrijwel hetzelfde kunt bereiken?

[Countess]

ik zeg toch niet voor niks kunnen maken. ik weet niet of ze dat gaan doen, maar dat is niet het punt.

en ik moet nog zien of ze met extensies even ver gaan komen, of zelfs maar in de beurt. geen van beide heeft een real-world voorbeeld kunnen laten zien.

[Verwijderd]

ik weet niet of ze dat gaan doen, maar dat is niet het punt.

Lijkt me wel, want jij reageert op: "Mantle is door AMD voor AMD. En dan zelfs specifiek GCN."
Als nVidia en Intel het niet ondersteunen (en AMD ook niet meer dan GCN ondersteunt), bljift dat statement dus gewoon waar.

[acemoo]

Mantle is door AMD voor moderne videokaarten gemaakt. Zowel voor AMD, Intel als Nvidia. De stelling dat Mantle door en voor AMD ontwikkeld is is dus gewoon fout. Ongeacht wat er mee gedaan word.

[Verwijderd]

De stelling dat Mantle door en voor AMD ontwikkeld is is dus gewoon fout.

Dat is ook niet de stelling.
Er staat niet 'ontwikkeld'.

Mantle is door AMD voor moderne videokaarten gemaakt.

Dus je geeft al toe dat het 'door AMD'-deel van de stelling juist is.

Het 'voor AMD'-deel klopt op dit moment ook, omdat Mantle op dit moment alleen beschikbaar is op bepaalde GCN-kaarten van AMD.

[acemoo]

Natuurlijk geef ik toe dat het 'door AMD'-deel van de stelling juist is. Dat zal ook niemand ontkennen. Natuurlijk niet. Maar daar gaat het niet om. Het gaat er om waar AMD het voor gemaakt heeft. En dat is voor moderne videokaarten. Ja het kan zijn dat er nooit support zal komen voor andere apparaten als GCN, betekend dat dat het er niet voor gemaakt is? Nee dat zou dan alleen betekenen dat AMD tevreden is met wat het resultaat van Mantle in OpenGL/DirectX is.

[Verwijderd]

Ja het kan zijn dat er nooit support zal komen voor andere apparaten als GCN, betekend dat dat het er niet voor gemaakt is?

Dat betekent dat er nooit drivers zijn gemaakt voor apparaten anders dan GCN.
Het is maar hoe je het statement interpreteert. Zoals ik zeg, in de context van welke drivers er daadwerkelijk gemaakt zijn, is het statement wel degelijk waar.

[Caelorum]

Niemand gaat toch betwisten dat Mantle niet door AMD is gemaakt. Het gaat om het "voor AMD. En dan zelfs specifiek GCN" stuk waar mensen over vallen en dat hebben ze nou juist niet gedaan, Ze hebben het voor alle relatief moderne kaarten gemaakt en dus ook hun eigen, maar niet specifiek voor GCN.

[Caelorum]

[...] De enige Mantle-drivers die beschikbaar zijn op dit moment, zijn voor AMD's GCN-kaarten.
In die zin heeft AMD het wel specifiek voor GCN gemaakt, letterlijk.
Dus het statement is in deze interpretatie wel degelijk waar.[...]

Nee, niet specifiek voor GCN gemaakt, maar *ook* voor GCN gemaakt. Dat is nogal een verschil.

[Verwijderd]

Nee, niet specifiek voor GCN gemaakt, maar *ook* voor GCN gemaakt. Dat is nogal een verschil.

Op dit moment zijn er ALLEEN drivers specifiek voor GCN gemaakt. Dat is een simpel feit. Waarom gaat dat er bij jou niet in?

[Caelorum]

Omdat een driver niet gelijk staat aan Mantle. Is toch niet zo moeilijk? Maar ben wel een beetje klaar nu. Jij bent toch niet te overtuigen.

[Verwijderd]

Omdat een driver niet gelijk staat aan Mantle.

Een driver is een noodzakelijke, maar niet voldoende voorwaarde voor Mantle bedoel je?
Dat ben ik met je eens. Verandert het verhaal niet: de enige hardware die drivers voor Mantle heeft, is AMD's GCN.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[Verwijderd]

Als 'DirectX' dichter bij de hardware wil.. is het zorgen dat het werkt op meerdere generaties en merken van chips dan de zorg voor DirectX of komt dat opeens bij de game ontwikkelaar te liggen?. Want dat laatste geeft me weinig hoop voor de resultaten.

Ik verwacht net als bij D3D10 een stap waarbij je een minimum spec voor de hardware hebt, maar dat het op zich verder onafhankelijk blijft van merk of type GPU. Bij de OpenGL-extensies hetzelfde verhaal.

Als een game-ontwikkelaar dus een code-path voor een bepaalde chipset heeft om minder overhead en meer efficientie te krijgen, kan er nog altijd op 'ouderwets Direct3D' worden terug gevallen voor generaties/chipsets die er dan buiten vallen natuurlijk. Zo zorg je tenminste dat het op z'n minst werkt.

Ja, dat zal een vergelijkbare situatie kunnen worden als destijds met D3D10: veel games hadden een D3D9-pad ernaast voor oudere hardware.

[BvZ]

Dit is een goede ontwikkeling!
Breede ondersteuining voor directX is er natuurlijk al!

[arendjr]

De grap is wel dat OpenGL deze functionaliteit waarover gesproken wordt grotendeels al heeft. Hier werd pas tijdens de Steam Dev Days ook al over gesproken: http://linustechtips.com/...s-talk-at-steam-dev-days/

Helaas worden deze nieuwe OpenGL-versies nog niet door alle drivers ondersteund, maar je kunt gewoon testen welke versie iemand heeft en dan van deze snellere calls gebruik maken als het ondersteund wordt, en anders terugvallen op de langzamere varianten. Hoewel dit natuurlijk wat extra werk kost van de developer is het nog steeds minder werk dan 2 volledige independent render paths te maken (1 voor OpenGL en 1 voor Mantle).

[ClementL]

Eigenlijk met name AMD´s drivers. Nvidia´s 400, 500, 600 en 700 series hebben al support voor OpenGL 4.4 .

[sharkwouter]

AMD ondersteunt OpenGL 4.3 en Intel ondersteunt OpenGL 4.0 op Windows en 3.3 op Linux.

[ClementL]

Dus Nvidia is de enige die full support voor bindless buffers heeft.

[madmaxnl]

Weet je hoeveel engines er gebruikt maken van OpenGL? Ik kan alleen de ID Tech 5 engine noemen. En alle games op Linux v.z.i.w. Gelukkig gamen er heel erg veel mensen op Linux en wordt die Tech5 engine veel gebruikt, not.

[ClementL]

Waar heb jij het nu over? De discussie ging over de aanwezigheid van low-end optimizations in OpenGL drivers, niet over het Linux marktaandeel (of überhaupt over Linux).

Enfin, nu je er toch over begint: je bent Unity 4, Unigine, Monogame(XNA) en Source 2 vergeten. De Unreal Engine 3 heeft ook een volledig functionerende Linux versie die door een aantal spellen gebruikt wordt (o.a. Dungeon Defenders en Killing Floor). Overigens is er ook een Linux versie van een op Cryengine draaiend spel onderweg.

Edit: Dan heb je ook nog de Serious Engine 3, maar die wordt alleen maar in Serious Sam gebruikt.

Edit2: Daarbij is ID Tech 5 één van de weinige engines die GEEN native support voor Linux heeft.

[Reactie gewijzigd door ClementL op 24 juli 2024 15:26]

[SJBijzitter]

RuneTek kan zowel OpenGL, DirectX, HTML5 en Java als renderer gebruiken.

[pduin]

AMD laat weten dat het bedrijf "graag de aangekondigde updates voor OpenGL en de DirectX-api's tegemoet ziet."

Ik geloof er niets van. Ik denk eerder dat AMD flink pissig is met de inhaalslag van de concurrentie omdat ze dan niet de enige meer zijn met een geoptimaliseerde API. Met als gevolg dat niemand meer voor Mantle gaat programmeren omdat het geen voordeel meer geeft ten opzichte van de concurrentie. Eventuele verkoop van licenties op Mantle technologie kunnen ze ook wel op hun buik schrijven dan.

[Verwijderd]

Als DirectX en OpenGL hetzelfde idee volgen als Mantle, zal AMD juist erg blij zijn. Minder CPU-kracht nodig in games is iets waar AMD ontzettend veel behoefte aan heeft, aangezien ze op dat punt niet echt mee kunnen komen met Intel.
Natuurlijk hebben ze liever dat hun eigen technologie de marktstandaard wordt, maar dat zou veel tijd en moeite kosten. Als de huidige marktstandaarden nu de filosofie van Mantle over gaan nemen gaat het (in theorie) allemaal een stuk sneller, wat uiteindelijk ook beter is voor AMD.

[Verwijderd]

Als DirectX en OpenGL hetzelfde idee volgen als Mantle, zal AMD juist erg blij zijn.

Lijkt me niet... AMD heeft eerst miljoenen geinvesteerd in een nieuwe API, en dan moeten ze het nog eens dunnetjes over gaan doen voor D3D en OpenGL.
Persoonlijk vind ik het hele idee van Mantle al fout. Waarom een nieuwe API verzinnen als het ook met OpenGL extensies kan, zoals nVidia dat doet (Direct3D is altijd wat lastiger, omdat je daar ook te maken hebt met MS en je concurrenten, maar OpenGL extensies kun je altijd uitbrengen)?
Dan heb je ook niet de kwestie of de concurrenten de API ook gaan ondersteunen of niet, want dan is het gewoon een onafhankelijke open standaard.

[Bintzak]

AMD CPU's komen ook niet altijd goed mee omdat de programma.s ook meer geoptimaliseerd zijn voor intel CPU's.

[Vetsmelter]

"Deze updates zouden de belasting op cpu's moeten verminderen"

Boeit enkel voor latency in communicatie. De echte CPU belasting is toch niet echt een probleem, zelfs bij AMD?

Ze zijn zeldzaam die reviews die aantonen dat vanaf een deftige resolutie de CPU quasi niks uitmaakt en het vooral de grafisch kaart de determinerende factor is.

Mijn Core 2 Quadcore van 2008 of Hexacore AMD 1090T zijn meestal niks aan het doen terwijl mijn Videokaart 7970 het uitzweet op 1920 x 1200.

[madcow22]

CPU is regelmatig helemaal vol met verschillende games daarom kan die mantle api ook z'n performance boost geven. Het is ongeveer het enigste wat het doen zorgen dat CPU belasting laag gehouden wordt en alles door de video kaart gedaan wordt.

[pduin]

"Als DirectX en OpenGL hetzelfde idee volgen als Mantle, zal AMD juist erg blij zijn."
AMD is blij als de concurrentie kan bijbenen?

"Natuurlijk hebben ze liever dat hun eigen technologie de marktstandaard wordt, maar dat zou veel tijd en moeite kosten."
Er is al een hoop tijd en geld in Mantle gestoken. Zou jammer zijn als Mantle zeer binnenkort alweer overbodig wordt.

"Als de huidige marktstandaarden nu de filosofie van Mantle over gaan nemen gaat het (in theorie) allemaal een stuk sneller, wat uiteindelijk ook beter is voor AMD."
Dan valt de meerwaarde van Mantle weg, en staat AMD weer op gelijke voet met NVidia.

[mark.waarden]

Ik ben van mening dat AMD dit wel graag tegemoet ziet beide kampen kijken bij elkaar in de keuken. Hetzelfde als wat er nu hardware matig gebeurd bij diverse hardware fabrikanten. Dus ik ben van mening dat dit alleen maar ten gunste is van ons als gebruikers.

[Verwijderd]

AMD heeft beide partijen flink in hun hemd gezet door simpelweg te laten zien hoeveel prestatiewinst er nog te winnen was. En ze moeten nu wel hierin mee want anders lopen ze achter op de concurrentie en dan ben je bekeken.

[Verwijderd]

Behalve dan dat nVidia al eerder was: http://www.slideshare.net/CassEveritt/beyond-porting
AMD heeft het gewoon veel meer uitgemolken dan nVidia in de media.

[Countess]

je bedoeld dat AMD ook echt een game heeft en meerdere onderweg terwijl nvidia niks heeft om te laten zien.

[Relief2009]

Hoezo in hun hemd gezet? Microsoft biedt al heel lang ondersteuning voor on the metal programmeren via de xbox. AMD heeft niets anders dan ervan geleerd en het naar de pc geport.

[_Dune_]

Eerst eens verdiepen in de materie voordat je zomaar iets gaat roepen. AMD heeft geen plannen om licenties af te geven tegen betaling, sterker nog het is de bedoeling om Mantel vrij in de markt te zetten voor een ieder die het wil gebruiken.

[master.fean]

Dat klopt, Mantle heeft als doel de AMD kaarten een edge te geven. Dan zou het heel erg dom zijn de Mantle SDK betaald te maken.

[TweakingRens]

Hij bedoelt daarmer dat het een open standaard wordt zoals OpenGL als het klaar is (neem ik aan).
Als nvidia het bijvoorbeeld wil kunnen zij dus ook mantle gaan gebruiken, maar ze zullen het uiteraard zelf moeten programmeren.

[master.fean]

Klopt en de AMD videokaarten zullen het dus als eerste hebben en daarmee een tijdelijke edge hebben, ook is het zo dat het een SDK uit het huis van AMD is en daarmee zullen zij het dus ook goed hebben optimaliseert voor hun eigen kaarten.

[TweakingRens]

Linus heeft toevallig een leuke video erover gemaakt:hier

[Bliksem B]

LOL ik hoopte op een leuk filmpje van Linus Torvalds, vanuit het oogpunt van de open source community. Kwam ik even bedrogen uit.... Voor mij niet veel nieuws...

[Countess]

AMD kiest partners om hun nieuwe API te testen en de fine-tunen waar ze al een goede band mee hebben.

hoe durven ze!

[Verwijderd]

Ik oordeel niet, ik stel het alleen vast.

[pduin]

De licenties zijn bijzaak, lees ook het woord 'eventuele' in mijn post. Het enige wat ik in mijn post zeg is dat het mij sterk lijkt dat AMD blij is met concurrentie.

[Countess]

fout op vele vlakken.

zoals al gezegd mantle word straks een open standaard, dus nik licentie geld.

maar nog veel meer zeggend, een van de DOELEN van mantel was het in beweging zetten van directX en openGL, nadat dat al jaren niet gelukt was via de normale manier. en dat is gelukt! dus wat mij en AMD betreft is mantle nu al een succes.

[pduin]

Het enige dat ik in mijn post zeg is dat ik me niet kan voorstellen dat AMD blij is met concurrentie op dit vlak, waarbij het tegengestelde wordt beweerd in de nieuwspost. Als de performance verbeteringen wegvallen ten opzichte van DirectX en OpenGL, wat voor meerwaarde heeft Mantle dan, zelfs al zou het een open standaard zijn?

[Countess]

de meerwaarde is dat openGL en directX in beweging zijn gezet wat de PC een interessanter game platform maakt, en dat er minder zware en dure CPU's nodig zijn om goed te kunnen gamen, zodat je met een AMD cpu net zo lang vooruit kan als met een intel en er geen rede meer is om een dure intel te kopen.

zoals gezegd een van de doelen van mantel was het in beweging zetten van openGL en directX. dat had AMD al vanaf het begin af aan gezegt nog voor deze aankondigingen.

[Verwijderd]

Het nieuws dat OpenGL en DirectX het voorbeeld van Mantle volgen

Pah, wat een onzin...
Een hoop van de besproken OpenGL-extensies bestonden al lang voordat Mantle uit was. Zie ook deze eerdere presentatie van nVidia: http://www.slideshare.net/CassEveritt/beyond-porting
Daar bespreken ze bv deze extensies:
http://www.opengl.org/registry/specs/ARB/buffer_storage.txt
http://www.opengl.org/registry/specs/ARB/sparse_texture.txt
https://www.opengl.org/re.../ARB/bindless_texture.txt
http://www.opengl.org/reg...B/multi_draw_indirect.txt
http://www.opengl.org/reg...hader_draw_parameters.txt
Juni 2013.
http://www.opengl.org/reg...storage_buffer_object.txt
September 2013.

En natuurlijk komen ook de nieuwe dingen in Direct3D ook niet uit de lucht vallen.
Je kunt het beter omdraaien: AMD heeft even snel met Mantle een snelle beta-hack uitgebracht, en probeert nu met de eer te strijken (Bij Direct3D en OpenGL moeten er nu eenmaal meerdere partijen het eens worden, en moet een en ander iets beter uitgekristalliseerd zijn voordat men het beschikbaar kan maken).
Ik krijg er nogal een vieze smaak van in m'n mond. Zeker omdat 'tech-sites' als tweakers klakkeloos aannemen dat AMD dit allemaal bedacht heeft, zonder zelf even de feiten te controleren. Daardoor zit het web nu vol met fanboys die claimen dat AMD met Mantle een of andere revolutie heeft ontketend.

Het is in ieder geval hopelijk nu voor iedereen wel duidelijk dat Mantle nooit door nVidia of Intel ondersteund gaat worden. Die blijven gewoon bij D3D en OGL. Mantle zal dus ook geen lang leven beschoren zijn.

Edit: Ja, mod maar weg hoor... Ik ben niet iemand die doorgaans klaagt over moderaties... Maar in dit geval is het natuurlijk diep triest om dit een -1 te geven. Het is gewoon de keiharde waarheid dat die OpenGL-extensies er al waren voor Mantle.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[Countess]

AMD heeft even snel met Mantle een snelle beta-hack uitgebracht

ze werken hier al 2 jaar aan. bijna al je openGL links komen uit 2013, en jaar NADAT AMD al aan mantle was begonnen dus. de 2 aprovals halverwegen 2012 zijn nog steeds 6 maanden nadat AMD al met mantle was begonnen.

Ik krijg er nogal een vieze smaak van in m'n mond. Zeker omdat 'tech-sites' als tweakers klakkeloos aannemen dat AMD dit allemaal bedacht heeft, zonder zelf even de feiten te controleren.

dat doen ze beter als jij die klakkeloos aanneemt dat AMD dit niet zelf bedacht kan hebben om een of andere reden terwijl een korte zoektocht je zou hebben verteld dat ze hier al langer aan werkte dan 3 maanden terug toen jij er voor het eerst over hoorden.

je wegmodderatie is dus (opnieuw) geheel terecht.

En natuurlijk komen ook de nieuwe dingen in Direct3D ook niet uit de lucht vallen.

aangezien er nog helemaal niks in software is ontwikkeld en het voorlopig enkel een slideshow is heb er helemaal geen enkele moeite mee om aan te nemen dat die dingen idd in de afgelopen 3 maanden uit de lucht zijn komen vallen.

[Reactie gewijzigd door Countess op 24 juli 2024 15:26]

[Countess]

ARB's klaar betekend niet geimplementeert of zelf maar geratificeerd voor release in de core openGL spec's, laat staat beschikbaar.

Mantle is nog steeds in beta. Dus wie was er eerder?

mantle heeft een game uit waar het in wordt gebruik, en meerdere in ontwikkeling, en kan duidelijk laten zien dat de CPU overhead enorm is gereduceerd.

openGL heeft... een video presentatie gesponsord door nvidia van eind vorige maand, waarvan we dus nog moeten zien hoeveel ze echt doen in een game.

Dus jij denkt dat het zo gaat van: "Oh, AMD heeft Mantle! Nou, dan moeten we snel een slideshow in elkaar draaien, en verzinnen we later wel hoe we dat in software gaan bouwen, en of er ook IHVs zijn die er hardware en drivers voor willen ontwikkelen!".

3 maanden of meer lijkt me toch ruim voldoende tijd om daar een goede gooi naar te doen met de juiste mensen. en vele malen geloofwaardiger als jouw versie waarbij AMD niks zelf bedacht kan hebben en daarom wel alles gejat zal hebben.

en wat heeft deze onderhuidse verandering met de hardware te maken? Mantle heeft laten zien dat alles veel efficiënter kan met de huidige hardware. dat ze er wat dingen bij gooien in die slideshow die ze in hardware willen implementeren en al aan bezig waren doet niks af aan het feit dat de focus van deze presentatie van MS een direct reactie is op Mantle.

[Reactie gewijzigd door Countess op 24 juli 2024 15:26]

[Countess]

En open specificaties van de functionaliteit, en drivers met ondersteuning beschikbaar voor iedereen.

waar niemand gebruik van maakt nog omdat het blijkbaar niet interessant genoeg is.

nergens is er iets te vinden over of deze extensies ook maar in de beurt kunnen komen van wat mantle laat zien wat cpu overhead betreft.

Nou nee, bij een nieuwe versie van D3D gaat daar jaren overheen.

de hardware ja. dat heeft echter weinig tot niks met de overhead van de API te maken zoals ik al had uitgelegd.

Vind je? De XB1 en PS4 zijn nou niet bepaald de eerste consoles. Consoles met low-level APIs bestaan al veel langer, evenals een hoop van de concepten waar Mantle zich van bedient.

nu al vergeten waar je het nog geen paar uur geleden over gehad hebt? daar was je beschuldiging dat AMD mantel van openGL en directX gejat zou hebben.

[Reactie gewijzigd door Countess op 24 juli 2024 15:26]

[Verwijderd]

waar niemand gebruik van maakt nog omdat het blijkbaar niet interessant genoeg is.

Het is niet bepaald een geheim dat OpenGL niet de populairste API is.

de hardware ja.

Ook de API.

dat heeft echter weinig tot niks met de overhead van de API te maken zoals ik al had uitgelegd.

Jawel dus. MS kan niet even in een paar maanden met een API komen waar 'toevallig' ineens de CPU-overhead aangepakt wordt, als reactie op Mantle. Daar is men al veel langer mee bezig.
En zoals je kunt zien doet nVidia ook al jaren hetzelfde met OpenGL extensies (ik had er al eentje uit 2010 gelinkt, elders).
Er zal dan ook flink wat kruisbestuiving zijn geweest tussen nVidia/OpenGL en Microsoft/Direct3D, achter gesloten deuren.De buitenwereld krijgt een nieuwe versie van Direct3D pas te zien in een later stadium.

[haarbal]

Mjah, onder opengl schijnt er al heel lang van alles te kunnen, maar het is blijkbaar toch lastig, want er zijn amper opengl games met een hoge productiewaarde, rage is de enige die ik zo even kan noemen, en dat was niet bepaald een vlekkeloze launch.

en idd een onterechte -1

[Reactie gewijzigd door haarbal op 24 juli 2024 15:26]

[Countess]

en idd een onterechte -1

ik verwacht dat mensen scalibq's hersenloze anti-mantle rants herrineren van andere mantle threads (waar hij onder andere tegen een developer van de frostbite engine die met mantle bezig is zegt dat die ongelijk heeft en dat hij het zelf beter weet, en vervolgens beschuldigt van partijdigheid en andere complot theorieën) en hem automatische wegmodden.

de discussie ging over of mantle ook ging werken op andere hardware als die van AMD. scaliq bleef volhouden van niet, ook al had hij nog nooit met mantle gewerkt, wist niks van de API af en had een frostbite developer tegenover zich die hem vertelde dat GPU specifieke functie zelfs expres uit de API waren verwijderd.

zo iemand kan je toch niet serious nemen?

[Reactie gewijzigd door Countess op 24 juli 2024 15:26]

[Crp]

Nee, inderdaad. Hij verpest een beetje de sfeer hier met zijn anti-AMD gedrag. Is misschien ook de reden geweest dat hij op verschillende fora is gebanned.
op Anandtech 2x zelfs

[haarbal]

ah, vandaar.

[BlaDeKke]

Het is in ieder geval hopelijk nu voor iedereen wel duidelijk dat Mantle nooit door nVidia of Intel ondersteund gaat worden. Die blijven gewoon bij D3D en OGL. Mantle zal dus ook geen lang leven beschoren zijn

Jammer genoeg gaat intel of nvidia er niets aan kunnen doen. Elke grafische kaart met unified shaders ondersteund het, willens of niet.

Dus in theorie zou Mantle op onderstaande generaties moeten kunnen draaien. Ik ga niet zeggen dat dit allemaal out of the box kan.

Graphics processors that have unified shading architecture include the Nvidia GeForce 8 series, Geforce 9 series, GeForce 200 Series, GeForce 400 Series, GeForce 500 Series, GeForce 600 Series, GeForce 700 Series, ATI Radeon HD 2000, Radeon HD 3000, Radeon HD 4000, Radeon HD 5000 series, Radeon HD 6000 series and Radeon HD7000 series S3 Chrome 400, Chrome 500, Intel GMA X3000 series, Xbox 360's GPU and others like the Qualcomm Adreno series

[Reactie gewijzigd door BlaDeKke op 24 juli 2024 15:26]

[BlaDeKke]

Heb het al edited, excuse me. Third party drivers...

[Reactie gewijzigd door BlaDeKke op 24 juli 2024 15:26]

[Telefooncal]

Ik ben benieuwd naar de uitwerking. Bij mantle in BF4 met een 7970 toch wel veel microstutters gehad, waarbij ik dat op DirectX toch niet had. Voor de product ontwikkelaars natuurlijk hardstikke leuk, maar er moet nog wel e.a gebeuren wil het écht lekker gaan werken...

[D33F]

Dat is iets wat elk nieuw product/technologie e.d. met zich meebrengt, er zullen altijd wat kinderziektes zijn die uiteindelijk gladgestreken zullen worden, gaandeweg leert men van fouten waardoor men zich kan verbeteren. Deze zaken zullen eerst in het wild moeten worden gegooid voordat men de tekortkomingen kan analyseren.

[Reactie gewijzigd door D33F op 24 juli 2024 15:26]

[Bever!]

nieuwe driver fixed het..

[dipje2]

Zolang het nog in een beperkte beta is zou ik niet zeggen dat dat 'aan mantle' ligt, maar gewoon aan de uitwerking ervan nu.

Commentaar altijd netjes voor je houden totdat de producent(en) zegt 'en nu is het klaar en je doet het er maar mee'. Tot die tijd is het speculatie (wat ook mag natuurlijk ).

[Paffelton]

Heb zelf ook de 7970.
Dat had ik ook toen die net uit was. De laatste tijd geen last meer van..

[XRayXI]

Heb je nieuwste beta geprobeerd? AMD Catalyst™ 14.2 Beta V1.3 Driver is uit: http://support.amd.com/en...atalyst-windows-beta.aspx

[Countess]

'micro' stutters?

met de eerste driver had ik elke zoveel minuten dat de FPS inzakte tot 0 voor een seconde of meer.

met de nieuwe drivers is veel beter. nog wel afentoe lage FPS, maar niet meer 0.

maar dat het nog niet vlekkenloos loop is niet zo gek, de API is nog in ontwikkeling en de drivers zijn nog beta. (en laten we eerlijk zijn, battlefield 4 is dat ook)

het zou daarom wel heel verzingwekkened zijn als het meteen vlekkenloos verliep.

[Jack77]

Wordt de 7970/280X intussen al ondersteund? De eerste Mantle-enabled-drivers waren in principe enkel voor gebruik met de 290/290X.

[Telefooncal]

de 7900 serie werd vanaf de mantle release direct ondersteund, alhoewel dit niet goed gedocumenteerd stond.

[Wampa1]

Zeer interessante ontwikkeling. Optimalisatie in de IT vind ik een van de mooiste dingen die er is. Lekker maximale performance eruit persen, en dat ook nog eens zonder al teveel overhead. Maar dan hebben we het weer over efficienty ^^.

[D33F]

Is dat niet sowieso een van de speerpunten waar IT om zou moeten draaien -> efficiency ?
Ik als programmeur streef er ook altijd naar om mijn code zo efficiënt mogelijk te maken waardoor je daadwerkelijk meer mogelijk kunt maken in the end.

[Reactie gewijzigd door D33F op 24 juli 2024 15:26]

[Fiander]

Dan ben jij als ontwikkelaar te duur. Het is goedkoper om meer hardware neer te zetten, dan dat jij één uur probeert iets te optimaliseren.

Helaas is bovenstaande opmerking er echt één die door ons management naar mij toe gedaan is

[ATS]

En terecht. Sterk geoptimaliseerde code is vaak lastiger te onderhouden en minder herbruikbaar. Dat maakt de code erg duur.

[kamerplant]

Ik ben benieuwd hoeveel procent performance nu verloren gaat aan driver-overhead, iemand een idee?

[BlaDeKke]

Het zou me verbazen dat iemand daar echt een vast percentage op kan plakken. Dit scheelt van game tot game, scene tot scene, hardware tot hardware. Maar als je op google gaat zoeken vind je wel benchmarks die laten zien hoeveel performace winst er is met Mantle op BF4. Dan heb je ongeveer een idee.

[Reactie gewijzigd door BlaDeKke op 24 juli 2024 15:26]

[Countess]

en bij die vergelijking moet je je ook nog realiseren dat er HEEL veel tijd is gestopt in het optimalizeren van de DirectX render path om extra overhead en threat stalls binnen directX te voorkomen, anders zou het verschil nog groter zijn.

[madcow22]

De enigste reden dat AMD mantle kan gebruiken om te boosten is omdat ze speciaal hardware support voor hebben gebouwd. Terwijl bij directx de bedoeling is dat alle vendors er door support kan worden.

[Countess]

nope. er zitten GEEN vendor specifieke functies in de mantle API. die zijn er zelfs expres UIT gehaald. (bron : prisonerofpain, frostbyte developer hier op tweakers)

[TweakingRens]

Als je kijkt naar hoe relatief mooi de XB360 en PS3 graphics kunnen zijn m.b.t. de kracht van de hardware: gigantisch. Als je een pc hebt met gelijkmatige hardware kom je helemaal nergens...

[Fiander]

Ik weet dat er destijds bij de eerste xbox ( celleron 733 ) 6000 DirectX calls per seconde mogelijk waren en op de zelfde hardware in pc form rond de 1000 . (ofzo... uit mijn blote hoofd)

Reken daar de iets weg voor het operating systeem. Blijft nog steeds een groot verschil over.

[AMD_Aero]

Mantle heeft dus voor iedereen nut gehad, die lijkt me een zeer nuttige toevoeging aan DX en OpgenGL.
Mantle heeft het allesinds in een stroomversnelling gebracht. Wat zeker goed is voor de dev's en de consument!

In het CJ topic waren we ooit tot dezelfde conclusie gekomen ookal zal Mantle niet perfect werken zal er wel voor zorgen dat de markt eens goed nadenkt bij de positie van DX.
Dit was één van de posts:
http://gathering.tweakers...message/41715907#41715907

[Verwijderd]

Mantle heeft het allesinds in een stroomversnelling gebracht.

Denk je echt dat logge organisaties als Microsoft en Khronos zo snel kunnen inspringen op iets als Mantle? De eerste game met Mantle is amper een maand uit. En AMD heeft nog niets gepubliceerd over hoe Mantle nu daadwerkelijk werkt, laat staan dat er een SDK beschikbaar is voor ontwikkelaars. Officieel hebben MS en Khronos nog niet eens naar Mantle kunnen kijken, want alleen de 'select few' zoals DICE hebben de beschikking over Mantle.

[D33F]

Zo zie je maar zodra iemand de eerste stap zet naar vernieuwing dan moet de rest wel snel volgen
Dat houdt ze onder elkaar scherp, en biedt uiteindelijk weer voordelen voor de consument/gebruiker.

[ClementL]

De functionaliteit waar ze hier waarschijnlijk over praten (bindless graphics) zit al een hele tijd als extensie in Nvidia´s open-source drivers. Carmack tweette hier vlak na de aankondiging ook al over. Deze functies zitten alleen nog niet in AMD´s GPU´s.