News DirectX 12 in erster Vorschau auf Augenhöhe mit Mantle

aim.star schrieb:
Angeblich hat AMD Mantle in ca ein bis zwei Jahren rausgehauen. Und die haben bei null angefangen.
Die haben aber auch nur sich selbst im Blick. MS muss die Wünsche von vier Hardwareherstellern unter einen Hut bringen. Hinzu kommt, dass die alte API nicht gebrochen werden darf und das die High-Level API weiterhin erhalten bleiben muss. DX12 ist keine reine Low-Level API.
Außerdem müssen sie noch viel mehr Plattformen berücksichtigen. Mantle läuft nur auf dem PC.
Das alles nimmt auch jede Menge Zeit in Anspruch und kann unter umständen länger dauern als eine API komplett neu zu entwickeln.

Den Forza Build halte ich uebrigens nicht fuer ein Paradebeispiel fuer DX12.
Es ging darum zu zeigen wie früh MS schon etwas lauffähiges vorzeigen konnte.

Das ist eine Black-Box bei der jemand sagt es sei DX12, nur was genau davon dann DX12 kann man nicht sehen. Wenn die nur auf einige neue Methoden zugreift und viel ueber irgenwelche DX11.x Legacy Funktionen macht ist das ziemlich unspektakulaer.
Es war jedenfalls eine PC Version des eigentlich nur auf XBox verfügbaren Spiels. Die haben das Spiel (zumindest eine Techdemo davon) innerhalb von ein paar Monaten mit DX12 API auf den PC portiert.

Modifizierter 3DMark11 schon auf der GDC 2014. Von dem spreche ich.

Aber zurueck zur Ursprungsfrage:
Gibt es Quellen die besagen das DX12 vor Mantle in Entwicklung war?
Nein. Die Frage wirst du auch niemals beantwortet bekommen.
 
Zuletzt bearbeitet:
Ich verstehe immer noch nicht, was das für eine Rolle spielt?
Das eine ist eine hardwaregebundene Insellösung....das andere eine Windows Schnittstelle die längst überfällig war.

MS pflegt damit ihr Xbox, Windows, Phone Ökosystem
 
UltraWurst schrieb:
Die vorhandenen Ressourcen werden also effizienter genutzt. :rolleyes:

Falsch....Mantle und DX12 nutzen die vorhandenen Ressorcen effizienter. (mehr Leistung bei weniger/gleicher CPU Last)
Der dolle "Wundertreiber" nutzt offenbar nur brach liegende Ressourcen denn die CPU Last steigt offensichtlich. (mehr Leistung bei mehr CPU Last)
 
PiPaPa schrieb:
Nicht ganz richtig. Adapative Sync ist nicht Grafikkarten-gebunden. FreeSync ist der Name des AMD Treiberparts der Adaptive Sync nutzt. Aber das haben sowohl Redakteure der Magazine, als auch das Marketing der Monitorhersteller zu verantworten...

schwer anzunehmen dass beide , Nvidia wie AMD, früher oder später 1:1 Adaptive Sync nutzen werden (oder von Beginn an Nutzen) und die Technisch einfach im Treiber und in der Werbung einmal FreeSync und einmal GSync heißt. :)
 
Wadenbeisser schrieb:
Der dolle "Wundertreiber" nutzt offenbar nur brach liegende Ressourcen denn die CPU Last steigt offensichtlich. (mehr Leistung bei mehr CPU Last)

Ja selbstverständlich nutzt der "Wundertreiber" (soll das höhnisch klingen?) nur brach liegende Ressourcen bzw. nutzt diese effizienter. Was denn sonst? Wie soll eine Software Leistung in einem Stück Hardware erschaffen, die da nicht vorher schon drin steckt? Es geht immer nur um Optimierungen.

Das ist ja der große Witz an der Sache: Seit Jahren schleppen wir ein aufgeblähtes DirectX mit uns herum und anstatt das Problem auf seiten der Software zu beheben, wird das Symptom mit neuer Hardware bekämpft.
 
noxon schrieb:
Die haben aber auch nur sich selbst im Blick. MS muss die Wünsche von vier Hardwareherstellern unter einen Hut bringen.

Geht auch andersrum: MS kann die API eigentlich so gestalten wie sie wollen, waehrend AMD auf die Wuensche von DICE eingehen musste. So S/W ist es nicht.

Hinzu kommt, dass die alte API nicht gebrochen werden darf und das die High-Level API weiterhin erhalten bleiben muss. DX12 ist keine reine Low-Level API.
Was im Endeffekt die Moeglichkeit eroeffnet die bisherige API einfach um neue Befehle zu erweitern und an den bisherigen ggf. ein paar Optimierungen vorzunehmen. Etwa DX11.3 + Overhead-Optimization = DX12.

Außerdem müssen sie noch viel mehr Plattformen berücksichtigen. Mantle läuft nur auf dem PC.
Das alles nimmt auch jede Menge Zeit in Anspruch und kann unter umständen länger dauern als eine API komplett neu zu entwickeln.
DX12 laeuft auf XB1, Windows 10 und Windows Phone. Die Plattformen haben nur schon eine API mit entsprechendem Entwicklerteam, deren Implementation der neuen API ist eigentlich relativ unabhaengig. Bei Windows Phone ist der Low-Level Part z.B. total uninteressant, die optimieren eher die High-Level Abstraktion.
Und das Mantle "nur" auf dem PC laeuft ist auch relativ, immerhin sind das dann mind. 3 Windows Versionen und das soll (sollte?) auch mal fuer Linux kommen.


Zu den Tech-Demos will ich mich hier nicht weiter aussern (wenn per PM), fand sie aber eher erbaermlich.

Die eigentlich fuer mich interessante Aussage ist ja nur
Nein. Die Frage wirst du auch niemals beantwortet bekommen.
 
aim.star schrieb:
Geht auch andersrum: MS kann die API eigentlich so gestalten wie sie wollen, waehrend AMD auf die Wuensche von DICE eingehen musste. So S/W ist es nicht.
Die können eben nicht machen was sie wollen. Abwärtskompatibilitäen einzuhalten ist eines der schwersten und undankbarsten Dinge die du in der Softwareentwicklung machen kannst.

Die Entwicklung von DirectX ist eine Kooperation zwischen Spieleentwicklern, GPU Herstellern und Microsoft. Microsofts interesse liegt natürlich darin die Wünsche aller zu berücksichtigen und eine API zu schaffen die allen zu Gute kommt und keinen vernachlässigt. Nur so wird sie auch genutzt.
In der Vergangenheit gab es auch oft Uneinigkeiten darüber was zu implementieren sein, doch bei DX12 soll es laut AMD diesmal wohl so wenig Unstimmigkeiten darüber gegeben haben wie noch nie. Alle waren sich wohl relativ einig darüber wie die API auszusehen hat.

Die einzigen, die hier ziemlich freien Spielraum hatten waren AMD. DICE hat hier selbstverständlich gar nichts zu entscheiden gehabt und waren lediglich Berater.

Was im Endeffekt die Moeglichkeit eroeffnet die bisherige API einfach um neue Befehle zu erweitern und an den bisherigen ggf. ein paar Optimierungen vorzunehmen. Etwa DX11.3 + Overhead-Optimization = DX12.
Jup. Genau das ist DX12. DX11 und ein paar Overhead Optimierungen. :rolleyes:

DX12 laeuft auf XB1, Windows 10 und Windows Phone. Die Plattformen haben nur schon eine API mit entsprechendem Entwicklerteam, deren Implementation der neuen API ist eigentlich relativ unabhaengig.
Was heißt hier unabhängig? Die API wird vom selben Team entwickelt. Das sind doch keine anderen Entwickler die dort die API entwickeln. Außerdem steckt ein Großteil der Arbeit auch nicht unbedingt in der Implementation sondern auch in der Spezifikation und die wird definitiv an einem gemeinsamen Tisch gemacht.

Bei Windows Phone ist der Low-Level Part z.B. total uninteressant, die optimieren eher die High-Level Abstraktion.
Unsinn. Gerade dort ist es relevant um den Energiebedarf gering zu halten.

Und das Mantle "nur" auf dem PC laeuft ist auch relativ, immerhin sind das dann mind. 3 Windows Versionen und das soll (sollte?) auch mal fuer Linux kommen.
Tut es aber nicht und wenn sich abzeichnet, dass Mantle keine aussichten auf Erfolg hat, dann wird es eventuell niemals für Linux erscheinen.
Es wird ja glNext geben. Warum also Mantle?


Zu den Tech-Demos will ich mich hier nicht weiter aussern (wenn per PM), fand sie aber eher erbaermlich.
Zum dritten Mal. Es ging nicht um die Demo an sich. Es geht darum, dass MS schon 6 Monate nach der Mantle Veröffentlichung lauffähige Portierungen von Benchmarks und Spielen mit DX12 API vorweisen konnten.
Das heißt also, dass sie definitiv nicht erst mit der Arbeit von DX12 begonnen haben, als AMD mit Mantle an die Öffentlichkeit getreten ist. Das ist alles.
Du kannst keine neue API in 6 Monaten spezifizieren, implementieren und dann ein Xbox Spiel mit dieser API auf den PC portieren.

Wenn du denkst, dass das geht, dann liegt das vielleicht daran, dass du denkst, dass DX12 nichts weiteres ist als DX11 + Optimierungen. Vielleicht solltest du dir dann mal ein paar der Developer Präsentationen oder MSDN Dokumentationen zu DX12 ansehen/durchlesen.
 
Nossi schrieb:
Ja selbstverständlich nutzt der "Wundertreiber" (soll das höhnisch klingen?) nur brach liegende Ressourcen bzw. nutzt diese effizienter. Was denn sonst? Wie soll eine Software Leistung in einem Stück Hardware erschaffen, die da nicht vorher schon drin steckt? Es geht immer nur um Optimierungen.

Das ist ja der große Witz an der Sache: Seit Jahren schleppen wir ein aufgeblähtes DirectX mit uns herum und anstatt das Problem auf seiten der Software zu beheben, wird das Symptom mit neuer Hardware bekämpft.

Da wird nichts effizienter weil dies bedeuten würde das man aus den gleichen Mitteln mehr Leistung raus bekommen würde aber man bekommt offenbar erzeugt der sogenannte Wundertreiber nur mehr Leistung durch die Nutzung von mehr Rechenleistung. Es muss keine Hardware erschaffen wenn sie schon ungenutzt da ist denn die Wohnung wird auch nicht größer weil man die Zimmertür auf macht und deshalb durch gehen kann.
Oder übertragen auf das Wohnungsbeispiel.....lasse 10 Mann in 2 gleich grosse 4 Raum Wohnungen gehen, wobei eine nur eine Tür mit eiinem Durchgangszimmer zu den anderen 3 hat und die andere 4. Wo kommt man schneller rein und raus?
 
Der Chip hat eine feste Rohleistung X. Die ist definiert durch die Architektur. Was man mit X nun anstellt ist allein Sache der Software und wie gut diese optimiert ist. Wenn ich nun Y Berechnungen anstellen möchte, dann benötige ich dafür Zeit t. Ist die Software gut optimiert, wird t kleiner. Ist die Software schlecht optimiert wird t größer. DirectX12 und Mantle vergrößern nicht X. Das ist unmöglich, denn X wird durch die Physik vorgegeben. DX12 und Mantle optimieren hingegen die Zeit t, weil sie die zur Verfügung stehenden Ressourcen effizienter nutzen. Sie optimieren das Verhältnis Y/t, was dazu führt, dass man entweder die selben Berechnungen in kürzerer Zeit erledigt oder mehr Berechnungen in der gleichen Zeit durchführt.
 
Zuletzt bearbeitet:
Wadenbeisser hat eben seine ganz eigene Definition von "Effizienz".
Das hat zwar nichts mit der Realität zu tun. Aber das ist ihm egal.
Unnötig, sich darüber noch weiter zu unterhalten.
 
@ Nossi
Ginge es CPU seitig um einen Singlecore hättest du sicherlich recht aber die Zeiten sind lange vorbei.

https://de.wikipedia.org/wiki/Effektivität
Der Unterschied zwischen Effektivität und Effizienz

Effektiv arbeiten bedeutet, so zu arbeiten, dass ein angestrebtes Ergebnis erreicht wird. Effizient arbeiten bedeutet, so zu arbeiten, dass erzieltes Ergebnis und eingesetzte Mittel in einem optimalen Kosten-Nutzen-Verhältnis stehen und der Nutzen dabei größer ist als die Kosten (ökonomisches Prinzip). Wobei sich die Kosten nicht ausschließlich auf monetäre Mittel beziehen, sondern auf alle negativen Konsequenzen der Aktion.
Angestrebtes Ziel (es geht schließlich um eine CPU Limitierung): Ausnutzung der verfügbaren CPU Leistung durch die Auslastung ALLER Kerne.
Der Prozessor wird nicht schneller aber er wird durch die bessere Lastverteilung besser ausgelastet und es ist dadurch mehr vorhandene Rohleistung nutzbar.
 
Cohen schrieb:
Und wie viele dieser 1000 Spiele sind Vollpreisspiele mit Multimillionen-Budget? Wie sieht es mit den Top-Sellern und "GOTY"-Kandidaten auf dem PC-Spielemarkt aus? FIFA, Assassin's Creed, Call of Duty, Far Cry, Metro, Crysis, GTA, Saints Row, Tomb Raider, Dragon Age, Mass Effect, The Elder Scrolls, Fallout, Diablo, BioShock, Die Sims...?

There is the current Counterstrike, Borderlands series, Witcher series, hah found one you mentioned even, Metro you talk about this Redux Series, its there for linux now. Then there are all Valve titles of course, Halflife 3 when it comes out, Portal series, Left for Dead Series.

And that is just that was is clear, BEFORE the "konsole" is out, how many AAA titles did you know of several months before PS3 came out. I find it very interesting offer, it targets console people AND pc people. And you know that a game you bought will run most likely in 20 years with the Steam Bos/Machine 10.
 
http://www.tomshardware.com/news/mic...dia,28606.html

We were also told that DirectX 12 will support all of this across multiple GPU architectures, simultaneously. What this means is that Nvidia GeForce GPUs will be able to work in tandem with AMD Radeon GPUs to render the same game – the same frame, even.

Ich habs mal hier her verschoben. Was ist davon zu halten? Das NVidia Karten mit AMD Karten unter DX12 vllt. zusammen arbeiten können?
Ich zweifel mal, dass NVidia/AMD das zu lassen werden bzw. überhaupt wollen. Für uns Kunden wäre das natürlich eine super Sache. :)
 
Die Frage ist doch vielmehr, wie der gerenderte Frame dann am Ende aussieht, denn es gibt ja z.B. bzgl. der Texturfilter durchaus leichte Unterschiede zwischen den beiden.

Verhindern werden sie es nicht können, da mit DX12 jede im System vorhandene GPU direkt von der Anwendung ansprechbar ist. Also prinzipiell würde auch ein triple SLI/Crossfire mit Intel, Nvidia und AMD funktionieren.
 
Müsste ja dann das Texturfiltern, Kantenglättung etc. vllt alles über DX12 laufen? Wäre aber schon ein sehr großer Aufwand.
Aber nützlich wäre es, könnte man in den Genuss der Technologien beider (aller drei) Seiten kommen.
 
Theoretisch ja, aber das Texturfiltern werden aus Performancegründen weiterhin die TMUs übernehmen müssen.
Um AA muss sich der Entwickler selber kümmern. Er kann auch so etwas wie 3xAA oder 5xAA mit beliebigen Sample-Verteilungen implementieren.
Das ist ja gerade eine der Neuerungen von Dx12 und Mantle: mehr Einfluss des Programmierers auf die Hardware.
 
Halte ich für Humbug bis es bestätigt wird. Das ist Wunschdenken. Man kriegt ja nichtmal Crossfire/SLI problemlos hin ohne als User ständig Hand anlegen zu müssen. Und nun soll DX12 das plötzlich alleine können, nicht nur mit unterschiedlichen Grakas vom selben, nein, sogar mit beliebigen Grakas und Herstellerunabhängig? Zusätzlich zu den sagenhaften Performancesteigerungen? Wenn ich eines gelernt habe, dann, dass technischer Fortschritt evolutionär und nicht revolutionär stattfindet.
 
DX11 ist ja auch nicht Multi-GPU-fähig, Dx12 schon. Und "von alleine" kann DX12 weniger als DX11, es liegt eben mehr in der Verantwortung der Programmierer.
Natürlich muss sich die"Multi-GPU-Programmierung erst einmal durchsetzen, das ist wie mit der Multi-Core Programmierung für CPUs.
 
Zurück
Oben