Multithread
Software-Overclocker(in)
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?
1. Brauche ich so viele Draw Calls?
2. Wieso dauert 1 Draw-call so lange?
Bei zweitem Setzt Mantle nun an, die zeit für einen Draw-call wird auf 10% von dem von DX gesetzt, sprich es wird unmengen Zeit frei auf der CPU.
Draw Calls lassen sich unter DX11 eben immer noch nicht leicht auf mehrere Threads aufteilen, deshalb auch die niedrige grenze von rund 10K stück.
Und so unperformant wie einige SFR darstellen, ist es gar nicht.
Speicherzugriffe erlaubt DX überhaupt keine, war einer der Kritikpunkte von DICE an der ersten Mantle Präsentation.
@ IceyJones umgekehrt: Programmierer müssen Draw-Calls zusammenfassen weil DX und OpenGL nicht in der Lage sind diese schnell genug zu verarbeiten, das wäre 'schöner' code.
Das was allerdings gemacht werden muss für DX, verunstaltet gewissermassen Teile des Codes. ganz ohne wird es wohl nicht gehen in naher zukunft, aber etwas erleichterung liegt ja wohl drin.
Ich hoffe sogar das es gleich so gemacht wird.Nur wenn das Spiel die Daten dann auch direkt in Format b liefert. Was aber auch unter DX/OGL möglich sein sollte.
Es sind da mMn zwei fragen die man sich stellen muss:Soweit ich das sehe, ist es bislang vor allen Dingen Entwicklungsaufwand: Die Engine muss Aufträge ansammeln und in einen Drawcall zusammenfügen, um alles mit einer akzeptablen Zahl von Calls zu übertragen. Derartige Aggregation sollte aber, im Vergleich zur Berechnung der eigentlichen Welt, wenig CPU-Last verursachen und es lässt sich prima in einen eigenen Thread auslagern. Für einen halbwegs aktuellen Quadcore vermutlich egal. Aber der Entwickler hat mit seiner Engine natürlich mehr aufwand, als wenn er jedes Ergebnis direkt rausfeuern kann.
1. Brauche ich so viele Draw Calls?
2. Wieso dauert 1 Draw-call so lange?
Bei zweitem Setzt Mantle nun an, die zeit für einen Draw-call wird auf 10% von dem von DX gesetzt, sprich es wird unmengen Zeit frei auf der CPU.
Draw Calls lassen sich unter DX11 eben immer noch nicht leicht auf mehrere Threads aufteilen, deshalb auch die niedrige grenze von rund 10K stück.
Muss Mantle auch nicht, PCI-E 2.0 sollte schon eine anständige Bandbreite abliefern.Ich sehe da nirgendwo einen Hinweis auf "1 Bild". Die Grafik zeigt nur, dass Mantle Aufträge verteilen kann. Da die Probleme von SFR nichts mit DirectX zu tun haben (im Gegenteil: während SFR für DirectX gar keinen Unterschied macht, muss man für Triple- und Quad-GPU sogar die DX-Specs aushebeln, um vernünftige Skalierung zu haben), tippe ich mal darauf, dass verschiedene Bilder gemeint sind. Mantle zaubert jedenfalls nicht die enorme Bandbreite zwischen den Karten herbei, die performantes SFR erfordern würde.
Und so unperformant wie einige SFR darstellen, ist es gar nicht.
GCN konnte ja schon zu Zeiten von DX11.0 Mega Texturen verwalten auf HW Basis, um mal ein Beispiel zu nennen, das war fast 2 Jahre bevor DX das gelernt hat.Wo steht das?
Und was für Befehle kann denn bitte schön eine GCN-DX11.2-Karte, die nicht über DX11.2 zugänglich sind![]()
Speicherzugriffe erlaubt DX überhaupt keine, war einer der Kritikpunkte von DICE an der ersten Mantle Präsentation.
@ IceyJones umgekehrt: Programmierer müssen Draw-Calls zusammenfassen weil DX und OpenGL nicht in der Lage sind diese schnell genug zu verarbeiten, das wäre 'schöner' code.
Das was allerdings gemacht werden muss für DX, verunstaltet gewissermassen Teile des Codes. ganz ohne wird es wohl nicht gehen in naher zukunft, aber etwas erleichterung liegt ja wohl drin.
), aber AMD verspricht, dass es einfacher wird. Deswegen würde es mich ja mal interessieren, was der Befehlssatz denn nun anders macht.



-> 

