APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Nur wenn das Spiel die Daten dann auch direkt in Format b liefert. Was aber auch unter DX/OGL möglich sein sollte.
Ich hoffe sogar das es gleich so gemacht wird.


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.
Es sind da mMn zwei fragen die man sich stellen muss:
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.

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.
Muss Mantle auch nicht, PCI-E 2.0 sollte schon eine anständige Bandbreite abliefern.

Und so unperformant wie einige SFR darstellen, ist es gar nicht.


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 :huh:
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.

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.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Hoffen wir einfach auf einen Performancegewinn von 1000%, damit wir BF4 mit 4K, 4MSAA, 200%RS und 60 FPS spielen können.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

super...ergo verleitet mantle die entwickler dazu, unsauber zu proggen, weil sie einfach die calls an die gpu raushauen können, ohne sinnvoll zusammenfassen zu müssen....
mittelfristig düstere aussichten für DX11-nutzer......ob es dann überhaupt nochmal optimierte games hierfür geben wird wenn die meisten entwickler erst für mantle proggen weil es ja einfacher für sie ist?!

Ob es unterm Strich einfacher wird, muss sich zeigen. Es kann viele Drawcalls besser abarbeiten - aber das ist eine kleine von sehr vielen Baustellen. Eigentlich ist low-level-Programmierung wesentlich aufwendiger (nutzt ja auch keine Spieleentwickler mehr reinen Assemblercode :schief: ), aber AMD verspricht, dass es einfacher wird. Deswegen würde es mich ja mal interessieren, was der Befehlssatz denn nun anders macht.
Ein Grundproblem bleibt für Entwickler aber auf alle Fälle: Mantle wird vorerst nichtmal 10% des potentiellen und vielleicht 30-35% des Kernmarktes erreichen. Also wird auch nicht zuuu viel Zeit darin investiert werden - zumal man für Mantle ja nicht optimieren muss, damit es flüssig läuft. Ist ja eh 10 mal so schnell ;)
Wichtiger wäre es für einen Entwickler da schon, auf einer Iris5000 spielbare Ergebnisse zu liefern. Denn das erweitert den Kundenkreis deutlich.
=> low-End-Optimierung. Nicht low-level.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Hat man nicht, zumindest nicht genug, das war ja einer der punkte die DICE gewollt hat bei Mantle;)

Man hat immer vollen Zugriff auf die GPU. Was denkst Du denn, was ein Treiber oder eine API ist?


Mantle läuft auf allen GCN GPU's, ist also nicht auf einem GPU begrenzt.

Ich habe auch nicht behauptet, dass Mantle nur für eine GPU ist. Bitte einfach nochmal meinen Post lesen.

@Alephtau
Kann man in etwa so stehen lassen
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Muss Mantle auch nicht, PCI-E 2.0 sollte schon eine anständige Bandbreite abliefern.

???
Normalerweise tauschen an einem Renderprozess beteiligte Elemente Daten mit >>100 GB/s aus und du willst ein <10 GB/s Interface nehmen? Das wird nichts. Überhaupt nichts.

Und so unperformant wie einige SFR darstellen, ist es gar nicht.

:ka:
Die letzten Benches, die ich gesehen habe, waren zu Gf6 Zeiten, als es kaum Bildschirmweite Effekte gab und nur das Geometrie-Setup eine saubere Teilung verhinderte. Damals wurden so um die 30% Skalierung erzielt. Heute würde ich mit <10% rechnen.

Speicherzugriffe erlaubt DX überhaupt keine, war einer der Kritikpunkte von DICE an der ersten Mantle Präsentation.

Und was will man mit Speicherzugriffen beim Rendering? Ich wüsste nicht, dass der Transfer von Texturen&Co zur Grafikkarte derzeit CPU-limitiert ist.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

super...ergo verleitet mantle die entwickler dazu, unsauber zu proggen, weil sie einfach die calls an die gpu raushauen können, ohne sinnvoll zusammenfassen zu müssen....
Das müsste nach dieser Logik aber auch jetzt schon so sein, da wir überwiegend Konsolenports spielen und die Konsolen ebenfalls über eine Low Level API verfügen.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Das müsste nach dieser Logik aber auch jetzt schon so sein, da wir überwiegend Konsolenports spielen und die Konsolen ebenfalls über eine Low Level API verfügen.

und? wie ist es?! warum zögern denn immer mehr studios, PC-ports rauszubringen?! eben........weil sie die optimierung fürchten.
und? wenn jetzt mantle es soooo einfach macht von konsolen-API zur mantle-API zu übertragen......warum sollten sie dann überhaupt noch für d3d/dx proggen?!
eben.....gar nicht.....

willkommen in der neuen pc-welt

generell gehen konsolen-games an AMD-rechner
und die anderen können froh sein, wenn M$ sich erbarmt, einen port für DX rauszubringen
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

und? wie ist es?! warum zögern denn immer mehr studios, PC-ports rauszubringen?! eben........weil sie die optimierung fürchten.
und? wenn jetzt mantle es soooo einfach macht von konsolen-API zur mantle-API zu übertragen......warum sollten sie dann überhaupt noch für d3d/dx proggen?!
eben.....gar nicht.....

willkommen in der neuen pc-welt

generell gehen konsolen-games an AMD-rechner
und die anderen können froh sein, wenn M$ sich erbarmt, einen port für DX rauszubringen

Armes Nvidia, tun mir ja jetzt schon leid. Haben ja sowieso schon so wenig Marktanteile und werden jetzt ohne Gegenwehr sang- und klanglos untergehen.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Man hat immer vollen Zugriff auf die GPU. Was denkst Du denn, was ein Treiber oder eine API ist?
Eben nicht, DX erlaubt keinen Vollzugriff auf die Hardware, deshalb ht sich DX auch vor 15 Jahren durchgesetzt, weil es einfacher war als alle anderen API's.

Ich habe auch nicht behauptet, dass Mantle nur für eine GPU ist. Bitte einfach nochmal meinen Post lesen.
Das möchte ich dir auch nicht unterstellen, tut mir leid das mein Post so rüber kam:(


???
Normalerweise tauschen an einem Renderprozess beteiligte Elemente Daten mit >>100 GB/s aus und du willst ein <10 GB/s Interface nehmen? Das wird nichts. Überhaupt nichts.
Ok, macht sinn.
Punkt für dich, habe ich schlicht übersehen.


:ka:
Die letzten Benches, die ich gesehen habe, waren zu Gf6 Zeiten, als es kaum Bildschirmweite Effekte gab und nur das Geometrie-Setup eine saubere Teilung verhinderte. Damals wurden so um die 30% Skalierung erzielt. Heute würde ich mit <10% rechnen.
Dann muss ich die >50% FPS gewinn in BF3 durch SFR wohl den Göttern zuschreiben.

Und nein, es ist kein AFR, denn MR sehe ich schon kurz unter 60FPS, mein Bild ist aber auch mit 40 FPS noch Flüssig, auch wenn das Spielen dann anfängt zäher zu werden, ist aber auch bei SGPU so.

Und was will man mit Speicherzugriffen beim Rendering? Ich wüsste nicht, dass der Transfer von Texturen&Co zur Grafikkarte derzeit CPU-limitiert ist.
Der Transfer selber ist nicht CPU Limitiert, aber die gesamte Vorbereitung und der Transport selber kostet aktuell zu viel CPU Leistung, dadurch geht auch etwas GPU Leistung durch warten verloren.

Durch den Direkten Speicherzugriff kann die Engine entscheiden was im VRAM bleiben soll, und muss sich nicht auf eine Schnittstelle verlassen die das übernimmt, dadurch kann zb. die menge der, über PCI-E zu übertragenden, Daten reduziert werden.

Ich nehme mal an die Engine weiss besser was sie nachher noch braucht als eine Schnittstelle.


PS: wenn du mir sagst woher ich ein FCAT Tool bekomme, immer her damit, dann würde ich gerne Benches amchen:)
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Was Mantle (vermutlich ermöglicht):
Direkte ACE Programmierung, mit dem GDS kann man unter Umständen vielleicht etwas machen, man hat keine festgelegte Rendering-Pipeline wie in DX, da kann die GPU paar Sachen auch anders ausführen.
GCN1.0 ist bei DX11.2 Tier 2 wegen möglicherweise trivialen Sachen gescheitert, mit Mantle kann man hier unter Umständen das meiste ebenso erreichen.

Und natürlich die direkte Verwaltung von dem ganzen Prozess, Carmack hat vor "Ewigkeiten" mal ein Interview gegeben:

Ryan Shrout: Focusing back on the hardware side of things, in previous years’ Quakecons we've had debates about what GPU was better for certain game engines, certain titles and what features AMD and NVIDIA do better. You've said previously that CPUs now, you don't worry about what features they have as they do what you want them to do. Are we at that point with GPUs? Is the hardware race over (or almost over)?

John Carmack: I don't worry about the GPU hardware at all. I worry about the drivers a lot because there is a huge difference between what the hardware can do and what we can actually get out of it if we have to control it at a fine grain level. That's really been driven home by this past project by working at a very low level of the hardware on consoles and comparing that to these PCs that are true orders of magnitude more powerful than the PS3 or something, but struggle in many cases to keep up the same minimum latency. They have tons of bandwidth, they can render at many more multi-samples, multiple megapixels per screen, but to be able to go through the cycle and get feedback... “fence here, update this here, and draw them there...” it struggles to get that done in 16ms, and that is frustrating.

Ryan Shrout: That's an API issue, API software overhead. Have you seen any improvements in that with DX 11 and multi-threaded drivers? Are those improving that or is it still not keeping up?

John Carmack: So we don't work directly with DX 11 but from the people that I talk with that are working with that, they (say) it might [have] some improvements, but it is still quite a thick layer of stuff between you and the hardware. NVIDIA has done some direct hardware address implementations where you can bypass most of the OpenGL overhead, and other ways to bypass some of the hidden state of OpenGL. Those things are good and useful, but what I most want to see is direct surfacing of the memory. It’s all memory there at some point, and the worst thing that kills Rage on the PC is texture updates. Where on the consoles we just say “we are going to update this one pixel here,” we just store it there as a pointer. On the PC it has to go through the massive texture update routine, and it takes tens of thousands of times [longer] if you just want to update one little piece. You start to advertise that overhead when you start to update larger blocks of textures, and AMD actually went and implemented a multi-texture update specifically for id Tech 5 so you can bash up and eliminate some of the overhead by saying “I need to update these 50 small things here,” but still it’s very inefficient. So I’m hoping that as we look forward, especially with Intel integrated graphics [where] it is the main memory, there is no reason we shouldn't be looking at that. With AMD and NVIDIA there's still issues of different memory banking arrangements and complicated things that they hide in their drivers, but we are moving towards integrated memory on a lot of things. I hope we wind up being able to say “give me a pointer, give me a pitch, give me a swizzle format,” and let me do things managing it with fences myself and we'll be able to do a better job.
John Carmack Interview: GPU Race, Intel Graphics, Ray Tracing, Voxels and more! | Interview Transcript

Alles nur für den Miesepeter ruyven. ;)


Und und und:

http://www.planet3dnow.de/cms/5655-...e-die-schnellste-3d-schnittstelle-entwickeln/
 
Zuletzt bearbeitet:
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Zugleich sollen Konfigurationen bestehend aus mehreren Grafikchips mit der API besser skalieren, womit auch Verbünde zwischen dedizierten und integrierten Grafikeinheiten der APUs gemeint sind.

Diesen Abschnitt finde ich ganz interessant. Könnte die APUs von AMD auf einen Schlag interessanter machen, vor allem wenn sie mal auch den CPU teil besser machen. Aber vor allem für SLI klingt dass gut, bis jetzt habe ich SLI-Verbunde einfach nie als preiswert angesehen da die dazugewonnene Leistung in keiner Relation zum Aufpreis steht. Falls aber mit Mantle eine zweite gleiche Grafikkarte eine fixe Mehrleistung von 90% bringt (momentan sinds ja so um die 70-80% oder?) und auch die Microruckler addressiert werden, bzw andere Probleme könnte SLI auf einmal ganz interessant werden.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Wichtiger wäre es für einen Entwickler da schon, auf einer Iris5000 spielbare Ergebnisse zu liefern. Denn das erweitert den Kundenkreis deutlich.
=> low-End-Optimierung. Nicht low-level.

Naja wenn schon wäre es wichtiger auf der HD 4600 spielbare Ergebnisse zu liefern und nicht bei nem Chip der relativ selten anzutreffen ist, weil er eben einfach zu teuer ist. Die HD 4600 hat dafür aber zu wenig Power und Chrystalwell wird es vermutlich in der nächsten Zeit immer noch nicht in günstigen Systemen geben.

Persönlich finde ich es eh interessanter, die Verbindung aus Mantle + Kaveri zu sehen. Damit könnten 1080p in mittleren Details gut machbar sein. Leider limitiert halt der schwache DDR3 RAM an der Stelle. Hier sollte AMD vielleicht doch noch überlegen es Intel gleich zu tun und "L4-Cache" mit auf die APU zu tun.

und? wie ist es?! warum zögern denn immer mehr studios, PC-ports rauszubringen?! eben........weil sie die optimierung fürchten.

Vor allem eher wegen den Absatzgefahren im PC-Markt. Spiele werden zum einen günstiger verkauft und zum anderen gibs noch die ganzen Raubkopierer. Da muss man halt abwägen, ob sich der Aufwand lohnt.
Außerdem heulen dann viele PC-Spieler rum mieser Port: schlechte Texturen, Steuerung und was weiß ich (siehe Dark Souls). Das wiederum hinterlässt auch noch nen Imageschaden, obwohls nur gut gemeint war. Weiterhin fehlen einem kleineren Studio auch vielleicht noch die Ressourcen.
Soll heißen: liegt nicht nur an der Optimierung.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Eben nicht, DX erlaubt keinen Vollzugriff auf die Hardware, deshalb ht sich DX auch vor 15 Jahren durchgesetzt, weil es einfacher war als alle anderen API's.

Da sind wir wohl gedanklich aneinander vorbeigelaufen.
DX übernimmt für den Programmierer den Hardwarezugriff unter Vorbehalt einiger Funktionen zu Gunsten der Kompatibilität.
Der Programmierer könnte jetzt an DX vorbei Zugriff auf die Hardware nehmen zu Lasten der Kompatibilität.
DX ist "nur" eine API.

Hardwarezugriff über DX
Programm --> DX --> (Treiber-API (AMD/NV/Intel etc.) --> Treiber (GPU)) --> GPU

Hardwarezugriff mit Mantle
Programm ---------> Mantle (=Treiber-API) -------------> Treiber (GPU) ---> GPU
Mantle ? --------------------------------------------> GPU

direkter Hardwarezugriff
Programm ----------------------------------------------------------------> GPU
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Wichtiger wäre es für einen Entwickler da schon, auf einer Iris5000 spielbare Ergebnisse zu liefern. Denn das erweitert den Kundenkreis deutlich.
=> low-End-Optimierung. Nicht low-level.

Wie gut, dass mit Kaveri eben jenes low-end auch von low-level profitieren wird. Das ist sogar eines der ausdrücklichen Designziele von Mantle.

32-apu13-mantle.jpg

(Viele viele weitere Folien: http://www.planet3dnow.de/cms/5655-...schnittstelle-entwickeln/subpage-alle-folien/)
 
Zuletzt bearbeitet:
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Eben nicht, DX erlaubt keinen Vollzugriff auf die Hardware, deshalb ht sich DX auch vor 15 Jahren durchgesetzt, weil es einfacher war als alle anderen API's.

Einfacher war DirectX nur im Vergleich zu OpenGL (was kein bißchen hardwarenäher ist). Die propietären APIs sind an der fehlenden Hardwareverbreitung gescheitert, nicht an ihrer Komplexität.

Dann muss ich die >50% FPS gewinn in BF3 durch SFR wohl den Göttern zuschreiben.

Und nein, es ist kein AFR, denn MR sehe ich schon kurz unter 60FPS, mein Bild ist aber auch mit 40 FPS noch Flüssig, auch wenn das Spielen dann anfängt zäher zu werden, ist aber auch bei SGPU so.

In der Tat überraschend hohe Werte. Auf welchem Wege aktivierst du SFR?

Der Transfer selber ist nicht CPU Limitiert, aber die gesamte Vorbereitung und der Transport selber kostet aktuell zu viel CPU Leistung, dadurch geht auch etwas GPU Leistung durch warten verloren.

Durch den Direkten Speicherzugriff kann die Engine entscheiden was im VRAM bleiben soll, und muss sich nicht auf eine Schnittstelle verlassen die das übernimmt, dadurch kann zb. die menge der, über PCI-E zu übertragenden, Daten reduziert werden.

Ich nehme mal an die Engine weiss besser was sie nachher noch braucht als eine Schnittstelle.

Das stimmt sicherlich und könnte in der Zukunft ggf. ein bißchen VRAM sparen. Aber Mantle soll ja auf heutigen Karten deutlich mehr Leistung bringen - und wer spielt heute schon so, dass Daten nicht im VRAM vorrätig gehalten werden können? Bei aktuellen Konfigurationen würde sich ein Vorteil nur für Iris pro (ohne Mantle) und die X1 (auch kein Mantle) ergeben, die ihre Caches effizienter nutzen können.

PS: wenn du mir sagst woher ich ein FCAT Tool bekomme, immer her damit, dann würde ich gerne Benches amchen:)

Ich dachte, FCAT wäre frei erhältlich. Problematischer ist da schon die Video-Capture-Einrichtung ;)
Aber das ganze braucht man eigentlich nur, um unregelmäßige Frametimes aufzudecken - um die es hier bislang nicht geht.


Was Mantle (vermutlich ermöglicht):
Direkte ACE Programmierung, mit dem GDS kann man unter Umständen vielleicht etwas machen,

Trotz längerer Recherche unter sehr vielen PC-bezogenen Deutungen von "ACE" und "GDS" habe ich keine einzige gefunden, die etwas mit Rendering zu tun hat :huh:


man hat keine festgelegte Rendering-Pipeline wie in DX, da kann die GPU paar Sachen auch anders ausführen.
GCN1.0 ist bei DX11.2 Tier 2 wegen möglicherweise trivialen Sachen gescheitert, mit Mantle kann man hier unter Umständen das meiste ebenso erreichen.

Und natürlich die direkte Verwaltung von dem ganzen Prozess, Carmack hat vor "Ewigkeiten" mal ein Interview gegeben:

John Carmack Interview: GPU Race, Intel Graphics, Ray Tracing, Voxels and more! | Interview Transcript

Hmm - das Rage mit seinen Megatextures leichte Probleme im Umgang mit Texturen unter damaligem DX hatte, überrascht jetzt nicht wirklich ;)

Alles nur für den Miesepeter ruyven. ;)

:-( -> :-|


Wie gut, dass mit Kaveri eben jenes low-end auch von low-level profitieren wird. Das ist sogar eines der ausdrücklichen Designziele von Mantle.

Wenn sich Kaveri gut verkauft, ist das sicherlich ein netter Aspekt. Aber für die Entwickler zählt heute erstmal die verbreitete Hardware. Und die unterstützt Mantle nur auf einigen Grafiklösungen von der Mittelklasse an aufwärts - nicht im low-end-Bereich.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Trotz längerer Recherche unter sehr vielen PC-bezogenen Deutungen von "ACE" und "GDS" habe ich keine einzige gefunden, die etwas mit Rendering zu tun hat :huh:
Die ACEs sind die Asynchronen Compute Engines, für Compute Queues. Nvidia hat ähnliches mit dem GK110 eingeführt, HyperQ und die Grid Managment Units, welche per CUDA angesteuert werden können.
Daneben hat DX vermutlich nichts was den gemeinsamen Adressraum (Also die ganzen unterschiedlichen Buffer und Memory-Modies) einer Kaveri GPU angeht. OpenGL und OpenCL sind da schon weiter bzw. haben auf der Roadmap solche Sachen wenigstens markiert, auch die ACEs.
Der GDS ist der kleine Global Data Share.

Hmm - das Rage mit seinen Megatextures leichte Probleme im Umgang mit Texturen unter damaligem DX hatte, überrascht jetzt nicht wirklich ;)
Wo es natürlich Verbesserungen gegeben haben kann, aber Carmack spricht prinzipielle Probleme an und ich denke kaum, dass DX und OGL diese aus den Weg geschafft haben oder dies tun werden.
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Einfacher war DirectX nur im Vergleich zu OpenGL (was kein bißchen hardwarenäher ist). Die propietären APIs sind an der fehlenden Hardwareverbreitung gescheitert, nicht an ihrer Komplexität.
Und es lief auf allen GPU's. Deshalb ist Glide damals ja gescheitert.

In der Tat überraschend hohe Werte. Auf welchem Wege aktivierst du SFR?
Finde ich auch. Ich erzwinge es per Radeon Pro (Scissors), funktioniert ganz gut, ist aber eben 1-2 Min aufwand pro Spiel.
Deshalb wundern mich eigentlich auch diese aussagen das es nur wenige % bringen soll.

Deine Prozent werte kann ich aber für Metro LL @ Max Tesselation bestätigen, dann geht nichts mehr:D


Das stimmt sicherlich und könnte in der Zukunft ggf. ein bißchen VRAM sparen. Aber Mantle soll ja auf heutigen Karten deutlich mehr Leistung bringen - und wer spielt heute schon so, dass Daten nicht im VRAM vorrätig gehalten werden können? Bei aktuellen Konfigurationen würde sich ein Vorteil nur für Iris pro (ohne Mantle) und die X1 (auch kein Mantle) ergeben, die ihre Caches effizienter nutzen können.
Ich bin leider immer noch kein Mantle Experte. Aber VRAM hat es seit ca 2 Jahren wirklich genug da.

Von ESDRAM Programmierung verstehe ich auch zu wenig, nur das 32MB zu wenig sind, das verstehe ich:D


Ich dachte, FCAT wäre frei erhältlich. Problematischer ist da schon die Video-Capture-Einrichtung ;)
Aber das ganze braucht man eigentlich nur, um unregelmäßige Frametimes aufzudecken - um die es hier bislang nicht geht.
Ich habe im Netz nirgendwo eine Overlay Software gefunden die ich einfach downloaden kann, Capturing kann ich zb. per Afterburner/Fraps machen, dann habe ich zwar Tearing nicht drauf, aber skipped und Doppelt angezeigte Frames schon.
Mir ist bewusst das dies nicht perfekt ist, aber zusammen mit einer Fraps Frametime linie schon aussagekräftiger, wobei ich letzteres schon jetzt machen kann, muss mich da heute Abend mal ran setzten:)

Ich bin zwar appli, aber habe nichts mit DX zu tun, sonst hätte ich das längst selber gemacht.
 
Zuletzt bearbeitet:
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

wann kommen die ersten 1000Hz Monitore? 128 fache Kantenglättung? :D:ugly:
10 mal mehr Draw-calls heißt nicht, 10mal mehr Leistung, nur son kleiner Tipp von mir. Und ja, ich hab Deinen Smiley am Ende gesehen ;)

Ist ja nett, dass der Treiber die CPU jetzt effizienter nutzt. Aber dafür brauch ich keinen exklusiven Befehlssatz zwischen Software und Treiber, das hätte problemlos mit DX- oder, wenn M$ sich weigert, OGL-Befehlen gemacht werden können. (Was nicht nur für den PC als Plattform von Vorteil gewesen wäre, sondern auch für AMD, da automatisch auch bestehende Engines profitieren würden)
Scheinbar hatte aber weder M$ noch das Konsortium hinter OpenGL interesse daran, DX bzw OpenGL effektiver zu machen.

Doch! Und genau draum geht es bei Mantle. DirectX ist so konzipiert, dass irgendwann ein Flaschenhalseffekt (CPU oder Speicherbandbreite) auftritt. Das kann man nicht durch Treiberoptimierungen einfach ungeschehen machen. AMD und Nvidia hätten es längst getan, wenn es möglich wäre. Die Lösung ist eine neue API, die näher an der Hardware ist, also weniger Software-Ebenen zwischen Spiel und Grafikchip einführt und genau das ist Mantle.
Bitte was? DX soll einen Flaschhals erstellen. Woher nimmst Du die Info?

mantle wird höchstens im unteren performance sektor für furore sorgen.
es könnte entscheiden, ob spielbar oder nicht.

im high end bereich?!
wen juckt es, ob BF4 mit 90 oder mit 110 fps läuft?!?!

je performanter der PC, desto unbedeutender wird doch der draw-call bottleneck?!

und btw: soviel zur glaubwürdigkeit solcher folien:

http://s1.directupload.net/images/131113/leogfhrh.jpg
Ja, ich denke auch, Mantle wird eher darüber entscheiden, ob etwas noch spielbar ist oder eben nicht mehr.
Wobei ich auch sehe, das die Draw-Call-Limitierung bei High-End-Hardware ärgerlicher ist, weil viel Leistung einfach mit Warten verloren geht. Aber hier entscheidet es nicht über Spielbarkeit, hier würde man sich "nur" wünschen, das die Wartezeit kürzer ausfällt, amn die CPU effektiver nutzt und so detaillierte Grafiken bekommen könnte.

Was die Glaubwürdigkeit angeht: die haben einfach die Kantenlänge mal 10 gesetzt, nicht den Flächeninhalt :schief:

hier limitiert die pure rechenleistung der GPU. es bringt NIX, wenn diese mehr calls bekommt, wenn diese nicht in time berechnet werden können....
aktuelle spiele rufen 3-5000 calls pro frame ab. dx11 kann 10000. was jetzt 10 mal mehr calls bewirken sollen? keine ahnung. wenn das jemand mal erklären könnte?!
erst wenn spiele derart viele calls überhaupt produzieren, wirds doch interessant.....oder sehe ich den kern der sache nicht?!
fakt ist: im high end bereich sind wir NICHT cpu-limitiert (im sinne von call-lieferungen an die GPU) sondern GPU (im sinne von abarbeitung der calls) limitiert.

ich sehe die chancen von mantle eher im reduzierten overhead und somit effizienterer programmierung und somit schnellerer abarbeitung von befehlen in der GPU. und was DAS wirklich bringt, muss sich zeigen.....
Es werden deutlich mehr Draw-Call produziert als die 10.000 die DX11 kann.
Das aktuelle Spiele "nur" 3 bis 5 Tausend pro frame raushauen, liegt daran, das eben wegen der Begrenzung auf 10.000 viele Draw-Call zusammengefaßt und gruppiert werden.
Was viele aber nicht sehen: Gruppieren könnte man auch unter Mantle, sollten irgendwann mal die 100k zu wenig sein :devil:

Den Performancegewinn gegenüber Direct X verspricht OpenGL schon seit Jahren, aber wirklich gekommen ist da nix.
Man hört sogar immer weniger davon.
Ich finde, man hört immer weniger von DX, während OpenGL beständig wenig in den News auftaucht.

Man hat immer vollen Zugriff auf die GPU. Was denkst Du denn, was ein Treiber oder eine API ist?
Klar, Du kannst jede GPU direkt in vollem Umfang ansprechen. Aber wenn Du das machen willst, kommst Du nicht mehr dazu, auch noch ein Spiel zu programmieren ;)
Die API erlaubt eben keinen direkten Zugriff , sondern abstrahiert soweit, das es auf jeder GPU läuft, damit gleiben viele Funktionen ungenutzt.

und? wie ist es?! warum zögern denn immer mehr studios, PC-ports rauszubringen?! eben........weil sie die optimierung fürchten.
Nein, sie fürchten die bösen Raubkopierer, die es nicht gäbe, wenn wir alle nur ne Konsole zum Spielen hätten...
 
AW: APU13 Techday: AMD gibt erste Details zur Mantle-API bekannt - Zukünftig schnellste API?

Scheinbar hatte aber weder M$ noch das Konsortium hinter OpenGL interesse daran, DX bzw OpenGL effektiver zu machen.
Naja, M$ hat mit DX11.1 ja deutliche Performanceverbesserungen hingelegt (Win 8 mit BF4).

Was auch ziemlich deutlich aufzeigt wohin die Reise mit Mantle gehen dürfte, wenn alleine M$ aus DX nochmals 20% mehr Performance (gemessen am BF4 test von PCGH) raus holen konnte.
 
Zurück