News AMDs Mantle-API kommt auch für Linux

[Hardware_Hoshi]

Ich habe schon vor drei Posts verstanden, dass du das sagen willst. Was ich aber gesagt habe, ist: Das passiert schon heute. Was denkst du, ist in den großen Engines los, damit die so gut funktionieren? Die haben jede Menge herstellerspezifischen Kram drin.

Herstellerspezifisch ist nicht automatisch schlecht. AMD hat in letzter Zeit mehr Eigenkram als unbedingt notwendig. Mantle ist nur ein weiteres Beispiel hierfür. Die großen Engines sind Einheitsbrei, die grundlegend alles unterstützen müssen um einen möglichst großen Marktanteil zu erreichen.

Bei OpenGL wird das alles noch um ein Vielfaches schlimmer, weil jeder Treiber komplett anders ist und sich gerade Nvidia überhaupt nicht an irgendwelche Spezifikationen hält.

Trotzem funktionert der Kram besser. Das "Wie" ist nicht das Thema. Viel wichtiger ist was am Ende an Performance ankommt. Viele der Extensions müssen die Entwickler nicht einmal anrühren. Das passiert nach Ausfürhung des eigentlichen Codes.

Die Entwickler müssen nur ein paar zusätzliche Befehle in den Code schreiben und die Hersteller-Soße übernimmt die Ausführung selbstständig. Der Grundcode muss dafür kaum geändert werden und funktioniert weiterhin plattformübergreifend.

Doch, der Spieleentwickler kann das am Ende sehr wohl.

Ein Spezialist für DirectX kann nicht plötzlich auf OpenGL umlernen bzw. umdenken. Bei den Treibern ist es noch schlimmer. Selbst Windows gibt es große Unterschiede im Treibermodell.

Windows 7 =/= Windows 8 =/= Windows 8.1 ....

Jetzt behauptest du die unzähligen Linux-Distributionen wären alle gleich? Die Spieleentwickler haben darauf keine Auswirkungen. Genau das ist das fatale an Mantle, weil es tief im Treiber eingegraben ist.

Schwachsinn.
Schwachsinn.

Wie bitte? Alleine der Wechsel einer Release kann eine Software komplett hinfällig machen, weil bestimmte Funktionen nicht mehr unterstützten oder geändert wurden. Wer etwas anderes behautet, hat schlicht einen an der Birne! Einfach alles über einen Kamm scheren funktioniert in diesem Fall nicht. Bei AMD ist das im Falle Linux vergleichbar mit russischem Roulette!

Alleine die millionen Hilfe-Threads in denen versucht wird die Implementierungen auf verschiedenen Linux-Derivaten zu installieren oder debuggen sprechen Bände(!).

Entweder die Mantleimplementierung ist in beidem komplett oder gar nicht. Das ist ja gerade der Vorteil, den AMD hier hat. Wenn AMD hier für Entwickler Unterschiede erzeugt, ist das ein hausgemachtes Problem und ziemlich dämlich. Sollte nicht passieren, ganz besonders, wenn man bedenkt, dass sich Catalyst und der freie Treiber in Zukunft dasselbe Kernelmodul teilen sollen.

Nein, bei Linux oder open-source allgemein kann man auch Dinge teilweise implementieren. Es sollte nicht so passieren, tut es aber in der Realität.

Noch viel mehr Schwachsinn. Was sollen Fenstermanager und Compositor mit den Innereien einer Spieleengine zu tun haben? Hast du auch nur den leisesten Hauch einer Ahnung, wovon du hier faselst?

Auch wenn Spieleengine ein Modewort ist, beschreibt es eher den kompletten Inhalt eines Spiels (Steuerung, Sounds, Grafik, KI etc.). Mantle an sich hat damit ungefähr garnichts zu tun, da es sich hauptsächlich um eine Render-Engine handelt. Zugegeben, einige I/O-Logarithmen für die Hardwareseite sind ebenfalls dabei.

So gesehen ist Mantle nur eine Schnittstelle für die verschiedenen Bereiche, so auch z.B. für AMD-TrueAudio.

Zurück zum Thema:
-Das hat sehr wohl eine gewisse Berechtigung für die Oberfläche von Linux. Dort werden nämlich auch 2D-/3D-Effekte verwendet. Falls Mantle zum einsatz kommt, müssen diese entweder mühsam darauf angepasst werden oder eben eine andere Renderart finden.

Das ist der besagte Mischmasch, von dem du weiter oben noch behauptet hast, es gäbe ihn nicht. DirectX (Direct3D) nutzt solche Effekte für die Windowsoberfläche. Bei AMD-Linux gibt es vor allem hier immer wieder Probleme.

Doch. Solange du nicht Müll programmierst, der in SELinux hängen bleibt, läuft dein Code auf jedem aktuellen Linux. JEDEM.

Du machst es dir zu einfach!

Nein, tun sie nicht, und ich habe auch schon etwas dazu geschrieben: Sie performen sogar besser als unter Windows, aber die OpenGL Implementierung unter Windows ist halt auch schon unter aller Sau, da reißt das bisschen besser, das sie unter Linux ist, auch nicht mehr viel raus.

Ich schrieb...
"AMD-Treiber performen unter Linux generell äußerst schlecht."

Wenn man im Vergleich zur Konkurrenz teilweise 30 bis 50% verliert, ist das doch nicht besser als unter Windows. MS nutzt eine ältere Version von OpenGL um ihr DirectX nicht zu gefährden. Das ist bekannt und allseits verteufelt. Dennoch erkärt es nicht, wieso Linux so vernachlässigt wird.

Zahlen lesen will gelernt sein, du kannst das ganz offenbar nicht.

Ich hoffe der englische Artikel hat dich nicht überfordert!

Kurz gesagt ist AMD nur gut in synthetischen Benchmarks und OpenCL. Wenn du dann auf die Anwendungsszenarien in den Spielen schaust, fällt die Leistung im Vergleich stark ab. Das heißt nichts anderes als mies programmierte Treiber. Die Rohleistung wäre da, aber AMD verschenkt diese einfach.

Zustätzlich ist das ganze Konstrukt instabil ohne Ende.

Ich muss da nichts googlen, ich bin seit JAHREN AMD Nutzer unter Linux. Ich habe sowohl Catalyst und noch nicht einmal Catalyst als auch den freien Treiber von vollkommen unbenutzbar und unfunktional zu tatsächlich brauchbar gehen sehen, ich habe Catalyst benutzt, als man Catalyst nutzen musste und bin zum freien Treiber gewechselt, sobald dieser DPM konnte.

Catalyst ist nur in der properitären Treibervariante von AMD. Der freie Treiber hat es soweit ich weiß nicht. Die Nutzer regen sich gerade darüber auf, dass es direkt von AMD kommt. Vom freien Treiber wäre man nicht so enttäuscht.

Die Wartezeiten sind hauptsächlich dem großen Nachholbedarf des freien Treibers anzuschulden, und seit GCN 2.0 ist das freie Team gleichauf mit dem proprietären, ich vermute mal stark, dass die teils sehr schlechte Catalyst Performance für einige der neuen Karten eben daher kommt, dass man das proprietäre Kernelmodul intern schon aufgegeben hat und nur noch auf den Umstieg wartet.

Das Eine hat nichts mit dem Anderen zu tun!

AMD ist zwar für Offenheit, betreut die Linux-Community, gibt aber nicht genügend oder nahezu keine Unterstützung. Der freie Treiber und die Catalyst-Version sind fast auf demselben Stand. AMD macht nicht mehr als sie eigentlich müssten. Zwischen dem Support von Linux und dem Windows-Treibern liegen Welten.

Bisher war AMD das egal, weil Linux nie im Fokus der Gamer stand. Doch jetzt kommt Valve und macht das Thema mit SteamOS populär. AMD muss reagieren oder sie verlieren einen weiteren Markt.

 

[Zehkul]

Herstellerspezifisch ist nicht automatisch schlecht.

Oh wow, und auf mehr wollte ich ja gar nicht hinaus. Schön, dass du es nun auch endlich verstanden hast. In Zeiten, in denen Engines immer größer und komplexer werden, in denen die meisten Studios einfach nur noch eine große Engine lizenzieren, wird das umso irrelevanter. Und gerade die großen Engines freuen sich nen Ast über Mantle, vor allem für Linux, müssen sie sich nicht mit AMDs schlechtem GL Code rumärgern.

Der Grundcode muss dafür kaum geändert werden und funktioniert weiterhin plattformübergreifend.

Schon OpenGL 3 Spiele müssen eine Menge Workarounds für Catalyst einbauen, GL4 ist bestimmt um ein Vielfaches schlimmer, weil das noch fast niemand versucht hat. Lies einfach den Artikel von Rich Geldreich, den ich immer verlinke, der spricht nicht umsonst von Extensions, die nur auf dem Papier funktionieren. Stattdessen einfach eine Mantleversion zu programmieren, dürfte in vielen Fällen tatsächlich schneller sein – oder überhaupt erst möglich, wenn Catalyst bei manchen Dingen einfach komplett aussetzt.

Ein Spezialist für DirectX kann nicht plötzlich auf OpenGL umlernen bzw. umdenken. Bei den Treibern ist es noch schlimmer. Selbst Windows gibt es große Unterschiede im Treibermodell.

Windows 7 =/= Windows 8 =/= Windows 8.1 ....

Aber diese Unterschiede haben keine Auswirkungen auf zum Beispiel den OpenGL Code. Warum sollte es bei Mantle anders sein? Natürlich brauchst du plattformspezifischen Code, aber der hat doch nichts mit dem Renderbackend zu tun.

Überhaupt, was hat das Ganze mit Mantle zu tun? Nichts, niet, nada, non. Du sprichst von generellem Portieren, nicht vom Renderpfad.

Wie bitte? Alleine der Wechsel einer Release kann eine Software komplett hinfällig machen, weil bestimmte Funktionen nicht mehr unterstützten oder geändert wurden. Wer etwas anderes behautet, hat schlicht einen an der Birne! Einfach alles über einen Kamm scheren funktioniert in diesem Fall nicht. Bei AMD ist das im Falle Linux vergleichbar mit russischem Roulette!

Du meinst also den Treiber? Ein Spielerechner hat immer den neuesten Treiber zu verwenden, das ist auch unter Windows bei AAA Spielen essentiell. Eine Distribution, die das nicht (einfach) erlaubt, taugt einfach nicht zum Spielen, Punkt. Verschiedene Distributionen haben verschiedene Anwendungsgebiete, es verwendet ja auch keiner CentOS als Desktopsystem. Wäre Schwachsinn.

Alleine die millionen Hilfe-Threads in denen versucht wird die Implementierungen auf verschiedenen Linux-Derivaten zu installieren oder debuggen sprechen Bände(!).

Hast du auch irgendeine Linuxerfahrung, die du nicht aus irgendeinem Thread hast?

Auch wenn Spieleengine ein Modewort ist, beschreibt es eher den kompletten Inhalt eines Spiels (Steuerung, Sounds, Grafik, KI etc.). Mantle an sich hat damit ungefähr garnichts zu tun, da es sich hauptsächlich um eine Render-Engine handelt.

Derartige Haare zu spalten ist an sich schon etwas ungemein Bescheuertes, noch bescheuerter wird das Ganze, wenn es gar keine Haare zu spalten gibt.
„mit den Innereien einer Spieleengine“
Merkste was? Nein, mit dem Begriff Innereien ist definitiv nicht Spiellogik gemeint, keine Ahnung, warum du das da reininterpretierst.

Und da du ja Haarspaltereien so zu lieben scheinst: Man muss den Begriff Engine schon verdammt weit fassen, um auch Dinge wie „Sounds“ miteinzuschließen, denn das sind Assets, das zur Engine zu zählen, ist ziemlicher Unfug. Deiner Beschreibung nach wäre das gesamte, fertige Spiel die Engine.

Zurück zum Thema:
-Das hat sehr wohl eine gewisse Berechtigung für die Oberfläche von Linux. Dort werden nämlich auch 2D-/3D-Effekte verwendet. Falls Mantle zum einsatz kommt, müssen diese entweder mühsam darauf angepasst werden oder eben eine andere Renderart finden.

Häh? Warum? Hör auf, von Dingen zu reden, von denen du null Ahnung hast. Im Fullscreen ist Compositing aus. Unredirect Fullscreen, nutzt eigentlich jeder moderne Compositor. Nix Effekte. Nada. Und auch wenn (ich glaube kwin macht hier seine Extrawurst, sollte aber auch einfach deaktivierbar sein über dbus bzw. ist ein einzelner Haken in den Einstellungen), hat doch mit Mantle nichts zu tun? Der Compositor ist ein separates Programm, was der an Leistung frisst und was der nachdem das Spiel Bilder ausgekackt hat mit eben diesen macht kann dem Spiel selbst vollkommen Schnurz sein. Ausnahme können hier höchstens Tiling WMs sein, aber wer die verwendet, ist eh Bastler und erwartet, in Probleme zu rennen, und außerdem hat das wieder mit dem Renderpfad überhaupt nichts zu tun, das ist ganz normaler plattformspezifischer Code, den du so oder so brauchst, egal ob du nun OpenGL, Mantle, Direct3D über den Gallium3D State Tracker oder o$e#^>@-Gl vom Planeten Knäcke 7 verwendest.

Du machst es dir zu einfach!

Na dann bring doch mal ein Beispiel, wo etwas auf einer Distribution läuft und auf einer anderen nicht. Wenn du fachlich so kompetent bist, sollte das ja kein Problem sein, oder? Ich habe schon ein Beispiel genannt, SELinux, in das Problem ist Valve mit irgendeinem enorm schlecht geschriebenen mp3 Decoder tatsächlich gerannt, der auf Speicher zugreifen wollte, auf den er eigentlich gar nicht zugreifen darf. SELinux hat das geblockt, auf Distributionen ohne SELinux lief es problemlos.

Also, deine kompetenten Beispiele?

Ich schrieb...
"AMD-Treiber performen unter Linux generell äußerst schlecht."

Und das ist eben falsch. Sie performen mittlerweile sogar besser unter Linux als unter Windows. Worin sie schlecht sind, schlechter als Nvidia, ist OpenGL, und zwar auch unter Windows.
Daher mein Kommentar zum Zahlen lesen. Will eben doch gelernt sein.

MS nutzt eine ältere Version von OpenGL um ihr DirectX nicht zu gefährden. Das ist bekannt und allseits verteufelt.

Und es ist genauso falsch, wie es bekannt ist. Ja, Microsoft liefert nur einen minimalen OpenGL Treiber mit, aber es installiert eh jeder seinen eigenen. (Man lese: Den von Nvidia/AMD)

Catalyst ist nur in der properitären Treibervariante von AMD. Der freie Treiber hat es soweit ich weiß nicht.

Hat was nicht? Und nein, da weißt du falsch, der freie Treiber wird genauso von AMD Angestellten entwickelt wie Catalyst.

AMD ist zwar für Offenheit, betreut die Linux-Community, gibt aber nicht genügend oder nahezu keine Unterstützung.

Welche Unterstützung fehlt dir denn? Ist alles fein säuberlich dokumentiert, neue Grafikkarten sind schon mit Gedanken an die freien Treiber designed (modularer UVD), da kann sich Nvidia mal eine Scheibe abschneiden. Nein, die Unterstützung der Open Source Community ist erstklassig, wäre lediglich schön, wenn AMD ein paar Entwickler mehr bezahlen würde, aber das bringt ja nicht unbedingt mehr freie Dokumentation.

Der freie Treiber und die Catalyst-Version sind fast auf demselben Stand. AMD macht nicht mehr als sie eigentlich müssten.

AMD hat zwei von grundauf verschiedene Treiber entwickelt, ich würde das schon „mehr als sie müssten“ nennen. Eher tut AMD zu viel, sie sollten weniger machen und dafür mehr Ressourcen für die einzelnen Projekte aufwenden. Passiert aber schon, Catalyst Kernelmodul wird entsorgt, hoffentlich Catalyst selbst innerhalb der nächsten 10 Jahre dann auch noch.

 

[roidal]

Jetzt behauptest du die unzähligen Linux-Distributionen wären alle gleich? Die Spieleentwickler haben darauf keine Auswirkungen. Genau das ist das fatale an Mantle, weil es tief im Treiber eingegraben ist.

Und wo ist da jetzt der Unterschied im Vergleich zu den OpenGL-Treibern?

Wie bitte? Alleine der Wechsel einer Release kann eine Software komplett hinfällig machen, weil bestimmte Funktionen nicht mehr unterstützten oder geändert wurden. Wer etwas anderes behautet, hat schlicht einen an der Birne! Einfach alles über einen Kamm scheren funktioniert in diesem Fall nicht. Bei AMD ist das im Falle Linux vergleichbar mit russischem Roulette!

Hier das gleiche, wo ist nun der Unterschied zu OpenGL, wobei du hier vermutlich sowieso mehrere Sachen zu vermischen scheinst.

Auch wenn Spieleengine ein Modewort ist, beschreibt es eher den kompletten Inhalt eines Spiels (Steuerung, Sounds, Grafik, KI etc.). Mantle an sich hat damit ungefähr garnichts zu tun, da es sich hauptsächlich um eine Render-Engine handelt. Zugegeben, einige I/O-Logarithmen für die Hardwareseite sind ebenfalls dabei.

So gesehen ist Mantle nur eine Schnittstelle für die verschiedenen Bereiche, so auch z.B. für AMD-TrueAudio.

Das widerspricht sich doch selbst? Es ist keine Rendering-engine, sondern wird von solchen verwendet.
Es ist eine Schnittstelle zwischen Rendering-engine und Grafikkarte, kümmert sich also darum, dass alles an der Grafikkarte ankommt.

-Das hat sehr wohl eine gewisse Berechtigung für die Oberfläche von Linux. Dort werden nämlich auch 2D-/3D-Effekte verwendet. Falls Mantle zum einsatz kommt, müssen diese entweder mühsam darauf angepasst werden oder eben eine andere Renderart finden.

Warum sollten die nicht einfach weiter OpenGL verwenden können?

Der freie Treiber und die Catalyst-Version sind fast auf demselben Stand.

Würde ich so jetzt nicht sagen. http://xorg.freedesktop.org/wiki/RadeonFeature/
Ausserdem ist der freie radeon-Treiber wesentlich langsamer, und es gibt auch Features/Funktionen welche lizenzrechtlich gar nicht implementiert werden dürften.

Lies einfach den Artikel von Rich Geldreich, den ich immer verlinke, der spricht nicht umsonst von Extensions, die nur auf dem Papier funktionieren. Stattdessen einfach eine Mantleversion zu programmieren, dürfte in vielen Fällen tatsächlich schneller sein – oder überhaupt erst möglich, wenn Catalyst bei manchen Dingen einfach komplett aussetzt.

Geldreich selbst schreibt ja das die AMD-Devs die OpenGL-Specs im Schlaf können, aber eben nicht in der Lage sind diese ordentlich in die Treiber zu implementieren, wer sagt das sie das bei Mantle besser können?

Du meinst also den Treiber? Ein Spielerechner hat immer den neuesten Treiber zu verwenden, das ist auch unter Windows bei AAA Spielen essentiell. Eine Distribution, die das nicht (einfach) erlaubt, taugt einfach nicht zum Spielen, Punkt. Verschiedene Distributionen haben verschiedene Anwendungsgebiete, es verwendet ja auch keiner CentOS als Desktopsystem. Wäre Schwachsinn.

Das ist natürlich ein bisschen übertrieben, aber es zeigt ziemlich gut wie komplex, und daher auch wie fehleranfällig, das ganze schon ist, sodass es bei neuen Spielen auch immer wieder zu Probleme kommt.

Na dann bring doch mal ein Beispiel, wo etwas auf einer Distribution läuft und auf einer anderen nicht. Wenn du fachlich so kompetent bist, sollte das ja kein Problem sein, oder? Ich habe schon ein Beispiel genannt, SELinux, in das Problem ist Valve mit irgendeinem enorm schlecht geschriebenen mp3 Decoder tatsächlich gerannt, der auf Speicher zugreifen wollte, auf den er eigentlich gar nicht zugreifen darf. SELinux hat das geblockt, auf Distributionen ohne SELinux lief es problemlos.

wow. Hast du dafür eine Quelle, würde das gerne lesen. Sowas sollte eigentlich nicht passieren.
Ausserdem stellt sich die Frage warum die einen mp3-decoder selbst schreiben, ist ja nicht so als würde es keinen für Linux geben.

AMD hat zwei von grundauf verschiedene Treiber entwickelt, ich würde das schon „mehr als sie müssten“ nennen. Eher tut AMD zu viel, sie sollten weniger machen und dafür mehr Ressourcen für die einzelnen Projekte aufwenden. Passiert aber schon, Catalyst Kernelmodul wird entsorgt, hoffentlich Catalyst selbst innerhalb der nächsten 10 Jahre dann auch noch.

Haben sie meines wissens nach nicht, radeon wurde und wird von anderen Entwickelt, AMD hat irgendwann mal angefangen das Entwicklerteam mit eigenen Leuten zu unterstützen, also mehr eine Zusammenarbeit.

 

[Hardware_Hoshi]

In Zeiten, in denen Engines immer größer und komplexer werden, in denen die meisten Studios einfach nur noch eine große Engine lizenzieren, wird das umso irrelevanter. Und gerade die großen Engines freuen sich nen Ast über Mantle, vor allem für Linux, müssen sie sich nicht mit AMDs schlechtem GL Code rumärgern.

Ich frage noch einmal:
Wieso soll man als Entwickler explizit für Mantle programmieren?

Linux hat weniger als 1,5% Martkanteil im PC-Segment.
AMD hat ~30% Marktanteil an diskreten Grafikkarten
Davon haben nur sehr wenige überhaupt eine neue GCN-Radeon für Mantle

Normalerweise entwickelt man für einen möglichst großen Kunden stamm. Wer das nicht tut, arbeitet hinter seinen Möglichkeiten. Gerade OpenGL hat den Hauptvorteil der Plattformunabhängkeit. Du Programmierst es und es läuft auf Linux, Android (OpenGL ES), Apple und sogar auf Windows.

Gehst du auf Mantle, hast du nichts gewonnen.

Hast du auch irgendeine Linuxerfahrung, die du nicht aus irgendeinem Thread hast?

Ja, jetzt wo du es sagst:
"Ich habe noch diesen Plüsch-Pinguin im Schrank. Da bin ich ganz stolz drauf!"

Na dann bring doch mal ein Beispiel, wo etwas auf einer Distribution läuft und auf einer anderen nicht. Ich habe schon ein Beispiel genannt, SELinux, in das Problem ist Valve mit irgendeinem enorm schlecht geschriebenen mp3 Decoder tatsächlich gerannt, der auf Speicher zugreifen wollte, auf den er eigentlich gar nicht zugreifen darf. SELinux hat das geblockt, auf Distributionen ohne SELinux lief es problemlos.

Also, deine kompetenten Beispiele?

SELinux ist ein Spezialfall. Eher sogar ist es ein Sonderfall. Das kannst du nicht als Referenz für alles nehmen.

Und das ist eben falsch. Sie performen mittlerweile sogar besser unter Linux als unter Windows. Worin sie schlecht sind, schlechter als Nvidia, ist OpenGL, und zwar auch unter Windows.
Daher mein Kommentar zum Zahlen lesen. Will eben doch gelernt sein.

Sag mir bitte an was du diese Meinung fest machst. Die meisten Spiele haben erheblich weniger FPS als unter Windows. Zusätzlich gibt es unzählige Bugs und Inkompatibilitäten. Die allgemeine Performance von AMD-Karten unter Linux kann man eindeutig unter "grottig" einordnen.

Und es ist genauso falsch, wie es bekannt ist. Ja, Microsoft liefert nur einen minimalen OpenGL Treiber mit, aber es installiert eh jeder seinen eigenen. (Man lese: Den von Nvidia/AMD)

Ja, das sind dann die OpenGL-Treiber, die man im Treiberpaket in Windows automatisch mitinstalliert. Das Featurelevel ist aber abhängig vom Grafikkartenmodell.

Hat was nicht? Und nein, da weißt du falsch, der freie Treiber wird genauso von AMD Angestellten entwickelt wie Catalyst.

Etwas komplizierter ist es schon. AMD engargiert sich sowohl für Closed-Source als auch für Open-Source-Treiber. Die community übernimmt aber zumeist die Entwicklung für die freien. AMD stellt gelegentlich Teile ihres Codes aus dem properitären Teil frei zur Verfügung. Die freien Entwickler wie z.B. Das Mesa-Team bauen dann darauf auf. Teilweise gibt es Lizenzprobleme. (GNU GPL)

Welche Unterstützung fehlt dir denn? Ist alles fein säuberlich dokumentiert, neue Grafikkarten sind schon mit Gedanken an die freien Treiber designed (modularer UVD), da kann sich Nvidia mal eine Scheibe abschneiden. Nein, die Unterstützung der Open Source Community ist erstklassig, wäre lediglich schön, wenn AMD ein paar Entwickler mehr bezahlen würde, aber das bringt ja nicht unbedingt mehr freie Dokumentation.

Fakt ist auch, dass AMD sehr schnell alte Modelle vom Support auslässt. Bei Nvidia und Intel laufen selbst alte Modelle sehr lange. Was die AMD-Linux-Geschichte angeht, das liegt alleine an der Community. Diese muss in den freien Treibern alles ausbügeln was AMD am Code verbrochen hat.

AMD müsste überhaupt eine vernünftige Entwicklungsabteilung für die Software haben. Die Jungs sind gnadenlos unterbesetzt. Unter diesen Umständen sollen die dann noch ein MOnster wie Mantle portieren? Viel Spaß!

AMD hat zwei von grundauf verschiedene Treiber entwickelt, ich würde das schon „mehr als sie müssten“ nennen. Eher tut AMD zu viel, sie sollten weniger machen und dafür mehr Ressourcen für die einzelnen Projekte aufwenden. Passiert aber schon, Catalyst Kernelmodul wird entsorgt, hoffentlich Catalyst selbst innerhalb der nächsten 10 Jahre dann auch noch.

Mit dem "mehr als sie müssten" kann man nicht einverstanden sein.
Die kürzere Version wäre:
"Sie murksen am Code herum!"

Frei + properitär ist zwar löblich, aber die Ergebnisse müssen auch stimmen. Selbst die freien Nvidia-Treiber (Nouveau) sind in Sachen Stabilität auf einem besseren Stand als AMDs properitäre Linux-Treiber. Das verstehe wer will!

 

[Multithread]

Ich frage noch einmal:
Wieso soll man als Entwickler explizit für Mantle programmieren?

Weil es einfacher und schneller als DX/OpenGL ist?
Das reicht vielen Spieleengineentwicklern schon aus als Grund.

Linux hat weniger als 1,5% Martkanteil im PC-Segment.
AMD hat ~30% Marktanteil an diskreten Grafikkarten
Davon haben nur sehr wenige überhaupt eine neue GCN-Radeon für Mantle

Ich gehe davon aus das der grosssteil der AMD Besitzer bereits GCN Karten hat.

Gehst du auf Mantle, hast du nichts gewonnen.

Viele Engine entwickler und user denken da ganz anders, und wenn es nur den Druck auf M$ erhöht um mit DX vorwärts zu machen.

SELinux ist ein Spezialfall. Eher sogar ist es ein Sonderfall. Das kannst du nicht als Referenz für alles nehmen.

Viele Engine entwickler und user denken da ganz anders, und wenn es nur den Druck auf M$ erhöht um mit DX vorwärts zu machen.

AMD müsste überhaupt eine vernünftige Entwicklungsabteilung für die Software haben. Die Jungs sind gnadenlos unterbesetzt. Unter diesen Umständen sollen die dann noch ein MOnster wie Mantle portieren? Viel Spaß!

Mantle ist kein Monster, OpenGL ist ein Treiber Monster, Mantle dürfte ziemlich wenig aufwand bei der erstellung und zur Portierung brauchen.
Das Sie unterbesetzt sind, ist leider so.

 

[Zehkul]

Geldreich selbst schreibt ja das die AMD-Devs die OpenGL-Specs im Schlaf können, aber eben nicht in der Lage sind diese ordentlich in die Treiber zu implementieren, wer sagt das sie das bei Mantle besser können?

AMD selbst hat Mantle gerade damit verkauft, dass sich Spieleentwickler über schlechte Treiber beschwert haben – „jetzt könnt ihr die Treiber selbst schreiben“. Mantle überlässt einfach viel mehr dem Entwickler. Ist wirklich eine tolle Idee von AMD, denn AMD beschäftigt sich viel lieber mit Hardware als mit Software.

wow. Hast du dafür eine Quelle, würde das gerne lesen. Sowas sollte eigentlich nicht passieren.
Ausserdem stellt sich die Frage warum die einen mp3-decoder selbst schreiben, ist ja nicht so als würde es keinen für Linux geben.

https://github.com/ValveSoftware/portal2/issues/50
Bei Dota2 sind sie auch öfters in SELinux gerannt. Etwas unnötig.

Haben sie meines wissens nach nicht, radeon wurde und wird von anderen Entwickelt, AMD hat irgendwann mal angefangen das Entwicklerteam mit eigenen Leuten zu unterstützen, also mehr eine Zusammenarbeit.

Nein, das war der alte RadeonHD Treiber, und der wurde mit dem neuen Radeonprojekt von AMD effektiv getötet. AMD war von Anfang (2007 dürfte das in etwa gewesen sein) an die treibende Kraft hinter dem Treiber. Vielleicht haben die damals noch woanders gearbeitet, weiß ich nicht, Geld kam aber von AMD, und heute arbeiten die Entwickler definitiv bei AMD.

Ich frage noch einmal:
Wieso soll man als Entwickler explizit für Mantle programmieren?

Also meinst du generell, und nicht nur bezüglich Linux? Tja, dann frag einfach die Entwickler, die das heute schon tun.

SELinux ist ein Spezialfall. Eher sogar ist es ein Sonderfall. Das kannst du nicht als Referenz für alles nehmen.

Was? Wo habe ich irgendwas als Referenz genommen? Ich habe nur ein Beispiel gebracht, in welcher Art von Programm es Probleme bei Distributionsunterschieden geben kann. Und über SELinux hinaus wirst du dabei nicht viel finden, sonst läuft am System nichts, was einem Spiel den Start verweigern kann.

Sag mir bitte an was du diese Meinung fest machst. Die meisten Spiele haben erheblich weniger FPS als unter Windows. Zusätzlich gibt es unzählige Bugs und Inkompatibilitäten. Die allgemeine Performance von AMD-Karten unter Linux kann man eindeutig unter "grottig" einordnen.

Oh Mann. OK, noch mal in ganz langsam, damit auch du es verstehst:

Wir haben Direct3D, wir haben OpenGL. Wir haben Nvidia Treiber, wir haben AMD Treiber. Willst du ein Spiel unter Linux laufen lassen, brauchst du OpenGL. Du soweit noch da? Schön. OpenGL läuft aber – oh Überraschung – auch genauso unter Windows. Nimmst du nun ein Spiel und portierst es für Linux, fängst du erst einmal damit an, es zu OpenGL zu portieren. Unter Windows. Am Ende hast du damit ein Spiel, das unter Windows mit Direct3D und OpenGL läuft, unter Linux nur mit OpenGL. Alles klar soweit? Mit dem Nvidia Treiber läuft das Spiel mit DirectX und OpenGL meist ziemlich gleich, ebenso läuft OpenGL unter Windows sowie Linux absolut gleich, Linux ist höchstens mal das ein oder andere Prozentchen schneller, wenn man am CPU Limit hängt.
Nun kommen wir zum AMD Treiber: Der ist leider ziemlich schlecht in Sachen OpenGL. Unter Direct3D läuft das Spiel absolut top, aber die OpenGL Version ist ziemlich lahm und instabil. Bedenke, wir befinden uns hier noch unter Windows. Gehen wir nun zu Linux rüber, zeigt sich hier in den letzten Monaten immer mehr das interessante Bild, dass der Treiber zwar immer noch längst nicht so gut mit OpenGL umgeht wie der von Nvidia, aber doch deutlich besser (und stabiler), als es derselbe Treiber unter Windows tut. Nun kapiert? Der AMD Treiber ist nicht schlecht unter Linux, er ist schlecht mit OpenGL.

Etwas komplizierter ist es schon. AMD engargiert sich sowohl für Closed-Source als auch für Open-Source-Treiber. Die community übernimmt aber zumeist die Entwicklung für die freien.

Nein, eben nicht. Schauste hier:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
Sieht man alle Namen derer, die Code zum Treiber beitragen. Und siehe da, die arbeiten fast alle bei AMD. AMD stellt auch ab und zu Leute aus der Community an, die sich gut am Treiber beteiligen, wie zum Beispiel vor etwas über einem Jahr Marek Olšák.

Was die AMD-Linux-Geschichte angeht, das liegt alleine an der Community. Diese muss in den freien Treibern alles ausbügeln was AMD am Code verbrochen hat.

Wenn man keine Ahnung hat …

Fakt ist auch, dass AMD sehr schnell alte Modelle vom Support auslässt.

Und was hat das mit Unterstützung für die Open Source Community zu tun? Support im freien Treiber gibt’s praktisch ewig, das ist das Schöne an Open Source.

Frei + properitär ist zwar löblich, aber die Ergebnisse müssen auch stimmen. Selbst die freien Nvidia-Treiber (Nouveau) sind in Sachen Stabilität auf einem besseren Stand als AMDs properitäre Linux-Treiber. Das verstehe wer will!

Nouveau, auch nur irgendwas können? Haha. Guter Witz. Nouveau scheitert doch schon am Reclocking.

Du hast ganz offensichtlich keinerlei Ahnung von Linux. Warum überlässt du das Beurteilen der Treiber nicht denen, die sie tatsächlich benutzen?

 

[roidal]

AMD selbst hat Mantle gerade damit verkauft, dass sich Spieleentwickler über schlechte Treiber beschwert haben – „jetzt könnt ihr die Treiber selbst schreiben“. Mantle überlässt einfach viel mehr dem Entwickler. Ist wirklich eine tolle Idee von AMD, denn AMD beschäftigt sich viel lieber mit Hardware als mit Software.



https://github.com/ValveSoftware/portal2/issues/50
Bei Dota2 sind sie auch öfters in SELinux gerannt. Etwas unnötig.

Lol. Wusste gar nicht das selinux standardmässig ein exec aufm heap verhindert.

Nein, das war der alte RadeonHD Treiber, und der wurde mit dem neuen Radeonprojekt von AMD effektiv getötet. AMD war von Anfang (2007 dürfte das in etwa gewesen sein) an die treibende Kraft hinter dem Treiber. Vielleicht haben die damals noch woanders gearbeitet, weiß ich nicht, Geld kam aber von AMD, und heute arbeiten die Entwickler definitiv bei AMD.

Ah, interessant. War auch der beste entschluss, der freie radeon-Treiber ist nämlich um einiges stabiler, wenn auch langsamer.
Auch wenn mir die entwicklung selbst von dem noch um einiges zu langsam geht, sollten ein paar mehr Leute drauf ansetzen, anstatt auf dem propritären.

 

[Krethi & Plethi]

https://www.youtube.com/watch?v=8uoD8YKwtww

 

[Zehkul]

Wow, SDK noch dieses Jahr? Das hätte ich nicht ganz so schnell erwartet. Daumen hoch, AMD! Fänds aber nur noch richtig gut, wenn sie die Zukunft von Mantle eben nicht nur in der eigenen Hand halten wollten. Nvidia und Intel an Board holen würde nicht wirklich schaden, Hauptsache es sind keine CAD Firmen drin. Wäre dann nämlich so ziemlich GamerGL.

 

[Dai6oro]

Habs auch eben entdeckt. Ein sehr informatives Gespräch.

PS: Versucht Hoshi wieder mal nen AMD Thread zu zerstören? Man kann sich ja kaum noch was von AMD im Titel durchlesen ohne dass Sontin und Hoshi herbeigesprungen kommen.

PPS: Das das SDK für Mantle noch diese Jahr kommt war glaub ich schon vorher bekannt.

 

[Krethi & Plethi]

naja, ich hab die beiden eh schon geblockt, ausser dummheiten kommt von denen eh nix^^

 

[Multithread]

SDK noch dieses Jahr?

Supi, dann kann ich mich ja bald dran setzten und damit rum experimentieren

 

[smilefaker]

Bin zu sehr realist um mich selbst zu belügen. AMD steht für Kompromisse und ich gehe mittlerweile keine Kompromisse mehr ein.

Welche Kompromisse sind das denn? Gerade Mantle spricht die Programmierer an, eben Kompromisse abzubauen und man geht mittlerweile auch davon aus, dass Mantle, wenn es ausgereift ist, wahrscheinlich den Beta und den teilweisen closed Source Status verlieren wird.
Dass AMD für Kompromisse steht ist eine unqualifizierte Müll Aussage und hat mit sachlicher Analyse nix zu tun!

Nvidia ist in OpenGL meilenweit vor AMD, deren Treiber unter Linux unter aller Sau sind.

DU vermengst Dinge die nix miteinander zu tun haben!

AMD-Treiber performen unter Linux generell äußerst schlecht. Als Vergleich nehme ich mal die GTX760, die eine R9-290 einfach stehen lässt. Da sind locker 200$ unterschied! Dazu noch gibt es tonnenweise Bugs und Probleme mit 3D-Darstellung (Flimmern & Blur), das Cataclyst-Center macht viele Leute wahnsinnig.

Auf der einen Seite argumentierst du, dass wenn Mantle für Linux kommt, es niemanden interessiert, aber auf der anderen Seite gewichtest du die Probleme die derzeit mit der OpenGL API von AMD unter Linux zu Problemen führen als riesiges Problem.
Da sind einfach die Gewichtungen nicht fair verteilt und offenbaren dass du nicht objektiv urteilen willst/kannst.

Mit so jemanden braucht man sich auch nicht weiter unterhalten, das ergibt keinen Sinn.

 

[Hardware_Hoshi]

Ich weiß einige User hier wollen es einfach nicht hören!

AMD geht die Luft mit Mantle aus. Alle diskutieren hier wie viel Mantle im Gegensatz zu OpenGL bringen wird. Das mag ja sein, aber nur wenn man den aktuellen Stand von Version 4.4 von Mitte 2013 betrachtet.

Die Khronoss-Group bastelt gerade and OpenGL 5.0, das laut aktuellen Diskussionen verschlankt und vereinfacht werden soll. Im Endeffekt hat man damit ähnliche Vorteile wie mit Mantle, ist aber weiterhin plattformunabhängig. Die Leistung wird steigen weil eben hardwarenäher programmiert werden kann.

Bei Windows hat man dann DirectX12 als Erstanlaufstelle. Davon werden Spiele auf OpenGL5.0 portiert. Erst danach wäre eine zusätzliche Integration von Mantle angedacht. Natürlich kann man auch gleich von DX12 auf Mantle gehen. Ich frage halt nur die ganze Zeit warum man das machen sollte!

Den einzigen Vorteil, den ich in Mantle sehe, ist dass es schon da ist. Bis Mitte 2015 werden dann aber die großen Player ihre neuen Schnittstellen gebracht haben. Dann verliert AMD nämlich alle Vorteile. Wer programmiert schon für eine zusätzliche API, wenn die Konkurrenz mit weniger Aufwand nahezu gleich oder eventuell besser ist? Zusätzlich legt man sich als Entwickler nicht selbst ketten an und unterstützt nur eine kleine Reichweite an Hardware.

 

[Multithread]

Ich weiß einige User hier wollen es einfach nicht hören!

AMD geht die Luft mit Mantle aus. Alle diskutieren hier wie viel Mantle im Gegensatz zu OpenGL bringen wird. Das mag ja sein, aber nur wenn man den aktuellen Stand von Version 4.4 von Mitte 2013 betrachtet.

Mit release wann? Kp, ob OpenGL 5 überhaupt vor DX12 kommen wird, im gegensatz dazu ist Mantle bereits da, und auf dem Aktuellen stand der Technick. Da hilft alles, von wegen am ende, nichts, Mantle ist aktuell die Non Plus Ultra API Für 3D Engines.
Das sieht man auch gut daran das sowohl Frostbite 3 als auch die nächste Cryengine Mantle wohl nativ mitbringen werden, und das sind beides Sehr grosse Player im Engine markt (Dutzende AAA Titel).

Die Khronoss-Group bastelt gerade and OpenGL 5.0, das laut aktuellen Diskussionen verschlankt und vereinfacht werden soll. Im Endeffekt hat man damit ähnliche Vorteile wie mit Mantle, ist aber weiterhin plattformunabhängig. Die Leistung wird steigen weil eben hardwarenäher programmiert werden kann.

Und mit dem Linux Release von mantle ist man nicht Platform unabhängig?
Wenn Intel wirklich mantle umsetzt sobald die API drausse ist, können sofort über 50% aller Rechner Mantle benutzen. Und dort dann egal ob Windows oder Linux.

Den einzigen Vorteil, den ich in Mantle sehe, ist dass es schon da ist. Bis Mitte 2015 werden dann aber die großen Player ihre neuen Schnittstellen gebracht haben. Dann verliert AMD nämlich alle Vorteile. Wer programmiert schon für eine zusätzliche API, wenn die Konkurrenz mit weniger Aufwand nahezu gleich oder eventuell besser ist? Zusätzlich legt man sich als Entwickler nicht selbst ketten an und unterstützt nur eine kleine Reichweite an Hardware.

Stimmt, wer programmiert schon für ne Zusätzliche schnittstelle, wenn man bereits eine Hat die das alles kann.
mantle ist bereits in verschiedensten Engines vertretten, das sind bisher weder DX12 noch OGL 5.0.

So wie ich das sehe, erhöht man durch die Unterstützung von ZUSÄZTLICHEN API's die unterstützung von verschiedenen Gaming Rigs. Da wird aktuell niemand ausgeschlossen.

Wenn die Implementation von mantle wirklich eifnach wird, würde mich eine breite Unterstützung in der Open Source Scene nicht wundern. So wie ich es aktuell sehe, ist Mantle der API Konkurenz noch rund 1,5 Jahre voraus, das ist in der Spielebranche ne menge Zeit.

 

[Daaron]

@Hardware_Hoshi: Ich hab bei den ersten Posts einen kleinen Kommentar zur Arbeitsweise und -effizienz der Khronos-Group abgelassen, den kann ich hier gern wiederholen.
Ist ja schön, dass die an OpenGL 5.0 basteln, aber mal ehrlich: So lahmarschig wie die Typen an ihrem Zeugs rummurksen, da haben wir DirectX14 und Mantle 3.0, bevor OpenGL5.0 wirklich verfügbar ist. Auf den Pfeifenverein würde ich keinen Cent setzen.

AMD geht nicht die Puste aus. Mantle ist, im Gegensatz zu DX 12 oder OGL 5.0, bereits verfügbar. Das Ding zeigt schon, was es kann. Es wächst mit den Wünschen der Spieleentwickler. Es ist NUR für Spieleentwickler. OpenGL krankt doch schon daran, dass jeder CAD-Heinz da seinen Kram durchgesetzt sehen will.
Entwickler können ihre Engines HEUTE auf Mantle portieren und gucken, was da geht. DX12- oder OpenGL5.0-Spiele wird es erst einige Monate nach Release der jeweiligen Schnittstelle geben, also im günstigsten Fall so in 18-24 Monaten. Die Entwickler haben also durchaus einen Vorteil darin, dass sie HEUTE für Mantle schreiben, weil sie damit 2 Jahre Umsatz machen können. Das wiederum sorgt für viel Erfahrung bei den Entwicklern mit Mantle, Erfahrung die bei DX12/OGL5.0 noch fehlt. Macht noch ein paar Monate Vorsprung.

 

[Hardware_Hoshi]

Mit release wann? Kp, ob OpenGL 5 überhaupt vor DX12 kommen wird, im gegensatz dazu ist Mantle bereits da, und auf dem Aktuellen stand der Technick. Da hilft alles, von wegen am ende, nichts, Mantle ist aktuell die Non Plus Ultra API Für 3D Engines.

Naja, so toll ist Mantle auch nicht. Es ist sehr stark auf die Szenarien abhängig. Die wenigen Mantle-Titel zeigen eindeutig, dass der Vorsprung von Mantle nicht allzu groß ist. Liegt wohl daran, dass Mantle aktuell eher eine Add-on-Portierung für bestehende DirectX-Games ist.

Wäre Mantle ohne weiteres super leicht von Grund auf zu programmieren und nicht auf AMD-Hardware beschränkt, würde ich dir sogar zustimmen. Das ist alles andere als Non-Plus-Ultra.

Das sieht man auch gut daran das sowohl Frostbite 3 als auch die nächste Cryengine Mantle wohl nativ mitbringen werden, und das sind beides Sehr grosse Player im Engine markt (Dutzende AAA Titel).

Frostbite 3 ist EA-exklusiv! Das nimmt der Geschichte schon einmal fahrt. Die Cryengine unterstützt prinzipiell alles. Man muss die Mantleteile weiterhin explizit ansprechen. Die Entwickler müssen weiterhin mehr Zeit in die Mantle-Implementierung stecken. Man muss schon wirklich AMD-Partner sein um sich das anzutun.

Und mit dem Linux Release von mantle ist man nicht Platform unabhängig?
Wenn Intel wirklich mantle umsetzt sobald die API drausse ist, können sofort über 50% aller Rechner Mantle benutzen. Und dort dann egal ob Windows oder Linux.

Intel ist erst einmal außen vor. Wahrscheinlich gehen sie den Weg mit DirectX oder OpenGL. Ohne Intel im Gepäck ist Mantle nichts.

Ob das Linux-Mantle plattformunanbhäng ist, glaube ich erst, wenn ich es sehe. Das hängt enorm von der Implementierung hab. Plattformunanbhängig nur für einen Hersteller kann man aber getrost wegwerfen. Das negiert sich gegenseitig!

Stimmt, wer programmiert schon für ne Zusätzliche schnittstelle, wenn man bereits eine Hat die das alles kann.
mantle ist bereits in verschiedensten Engines vertretten, das sind bisher weder DX12 noch OGL 5.0.

Mantle ist eine Nischen-Engine! DX12 und OGL 5.0 werden die neuen Ausleger von Industriestandards. Davon kann AMD momentan nicht einmal träumen.

So wie ich das sehe, erhöht man durch die Unterstützung von ZUSÄZTLICHEN API's die unterstützung von verschiedenen Gaming Rigs. Da wird aktuell niemand ausgeschlossen.

So lange Budgets sehr beschränkt und Releasetermine fest vorgeben sind, ist jede zusätzliche API ein Problem. Je mehr zusätzliche Unterstützung in weitere Grafikteile gesteckt werden, desto mehr leidet das Gesamtprojekt. Es treten mehr Bugs und Inkompatibilitäten auf.

Battlefield 4 ist dafür das Paradebeispiel. Ich habe schon gesagt wie verbreitet AMD überhaupt ist. Auf Linux ist die Sache sogar noch schlimmer! Für Entwickler macht es mehr sind auf größere Marktdurchdringung zu setzen.

Wenn die Implementation von mantle wirklich eifnach wird, würde mich eine breite Unterstützung in der Open Source Scene nicht wundern. So wie ich es aktuell sehe, ist Mantle der API Konkurenz noch rund 1,5 Jahre voraus, das ist in der Spielebranche ne menge Zeit.

Du vergisst dabei wie lange Mantle noch in der Beta-Phase sein wird. Die Schnittstelle läuft noch nicht wirklich rund. Bei Linux wird dasselbe der Fall sein. Im Hintergrund hört man Gerüchte dass Microsoft schon mit Entwicklern zusammen arbeitet um schnell DX12-Games auf den Markt zu bringen.

Das Gerede um Open-Source und Mantle ist so mühselig. Mantle ist nicht offen und wird es wohl auch nie werden. Die Community für ihren eigenen Missstände einspringen zu lassen, ist für AMD im Linuxsektor schon der Normalzustand. Wirft nicht gerade ein gutes Licht auf AMD-Support!

 

[Multithread]

Naja, so toll ist Mantle auch nicht. Es ist sehr stark auf die Szenarien abhängig. Die wenigen Mantle-Titel zeigen eindeutig, dass der Vorsprung von Mantle nicht allzu groß ist. Liegt wohl daran, dass Mantle aktuell eher eine Add-on-Portierung für bestehende DirectX-Games ist.

Mantle setzt auch genau DORT An wo DX und OGL versagt haben, nämlich der Mehrkernunterstützung, und das kann Mantle sehr gut, zusätzlich ist die schnittstelle fast immer schneller als DX, egal welche Konfig.
Schon mal aussagen von Entwicklern zu Mantle gelesen? DIe loben Mantle in den Himmel, für die ist das eine art befreiung. Ich glaube nicht alles was die sagen, aber wenn Leute mit Ahnung sagen das Mantle einfach ist, dann bin ich bereit daran zu glauben.

Wäre Mantle ohne weiteres super leicht von Grund auf zu programmieren und nicht auf AMD-Hardware beschränkt, würde ich dir sogar zustimmen. Das ist alles andere als Non-Plus-Ultra.

Man kann sogar, sobald man die API Doku hat, einen Mantle Treiber schreiben der auf einem Pentium 4 Laufen würde, Mantle ist nur ne API definition, mehr nicht, das kannst du für alles umsetzten. Nur die Frage ist wie Performant das ganze dann ist.

Frostbite 3 ist EA-exklusiv! Das nimmt der Geschichte schon einmal fahrt. Die Cryengine unterstützt prinzipiell alles. Man muss die Mantleteile weiterhin explizit ansprechen. Die Entwickler müssen weiterhin mehr Zeit in die Mantle-Implementierung stecken. Man muss schon wirklich AMD-Partner sein um sich das anzutun.

Nicht wirklich, die Frostbite 3 wird für Dutzende AAA Titel benutzt, fast jedes EA Game benutzt diese Engine, und damit kann auch fast jedes EA Game nativ Mantle.

Ich sehe nicht ein wieso man bei der Cryengine danach den Mantle pfad separat ansprechen müssen soll, damit würde Crytec die eigenen Kunden verärgern. Ausserdem würde ich mal Abwarten bis sich ein Entwickler der auf der Cryengine Entwickel dazu äusserd, vorher sind das Spekulationen ohne Hand und Fuss.

Intel ist erst einmal außen vor. Wahrscheinlich gehen sie den Weg mit DirectX oder OpenGL. Ohne Intel im Gepäck ist Mantle nichts.

Intel hat damit wenig am Hut, wenn die Entwickler Mantle wollen, werden die Graka hersteller nachgeben, liegt ja auch in Ihrem interesse das Games bei Ihnen schnell laufen, da unterschätzt du ganz stark die Macht des Marktes.

Ob das Linux-Mantle plattformunanbhäng ist, glaube ich erst, wenn ich es sehe. Das hängt enorm von der Implementierung hab. Plattformunanbhängig nur für einen Hersteller kann man aber getrost wegwerfen. Das negiert sich gegenseitig!

Mantle ist eine Nischen-Engine! DX12 und OGL 5.0 werden die neuen Ausleger von Industriestandards. Davon kann AMD momentan nicht einmal träumen.

Mantle ist keine Engine, Mantle ist nur eine Definition einer Schnittstelle, also Programmiertechnisch sowas:
abstract drawLine(point1, point1);

Das ist die ganze Mantle Definition, der Treiber muss diese FUnktionen nun können und die Engine aufrufen, Die Logik ist aber nicht Teil von Mantle.

Battlefield 4 ist dafür das Paradebeispiel. Ich habe schon gesagt wie verbreitet AMD überhaupt ist. Auf Linux ist die Sache sogar noch schlimmer! Für Entwickler macht es mehr sind auf größere Marktdurchdringung zu setzen.

BF4 war wohl ne art Testrun für die API, bei Thief und co lief es zum release dann schon bedeutend besser.

Das Gerede um Open-Source und Mantle ist so mühselig. Mantle ist nicht offen und wird es wohl auch nie werden. Die Community für ihren eigenen Missstände einspringen zu lassen, ist für AMD im Linuxsektor schon der Normalzustand. Wirft nicht gerade ein gutes Licht auf AMD-Support!

Mantle ist nicht offen blah blah....

So liest sich dein Text, das mag aktuell stimmen, aber die Doku wird wohl früher oder später Freigegeben, dann kann jeder nen Mantle Treiber oder/und ne Mantle fähige Engine schreiben. JEDER.


Wenn Mantle nicht offen ist, was ist dann mit PhysX, Cuda? Ach ja, richtig, die sind von NV, da geht das in Ordnung.
Sorry, aber das ist Kinderkram.

Am rande: Sprichst du irgendeine Programmiersprache? (HTML /CSS sind keine) Wenn nicht, kannst du hier kaum mitreden, da dir eine menge grundlegendes Verständnis Fehlt.

 

[TemplateR]

Nicht wirklich, die Frostbite 3 wird für Dutzende AAA Titel benutzt, fast jedes EA Game benutzt diese Engine, und damit kann auch fast jedes EA Game nativ Mantle.

Frostbite 3 Engine ist EA-Exklusiv und somit dürfen nur EA-Games damit ausgestattet werden:

http://www.gamestar.de/news/vermischtes/3024943/frostbite_3.html

 

[Hardware_Hoshi]

Mantle setzt auch genau DORT An wo DX und OGL versagt haben, nämlich der Mehrkernunterstützung, und das kann Mantle sehr gut, zusätzlich ist die schnittstelle fast immer schneller als DX, egal welche Konfig.
Schon mal aussagen von Entwicklern zu Mantle gelesen? DIe loben Mantle in den Himmel, für die ist das eine art befreiung. Ich glaube nicht alles was die sagen, aber wenn Leute mit Ahnung sagen das Mantle einfach ist, dann bin ich bereit daran zu glauben.

Zufällig sind diese Entwickler alle Partner von AMD(!). Natürlich loben die ihren Partner und ihre eigene Arbeit. Der REst der Entwickler ist nach wie vor gespalten. Niemand braucht eine weiter properitäre Grafik-Schnittstelle - niemand!

BF4 war wohl ne art Testrun für die API, bei Thief und co lief es zum release dann schon bedeutend besser.

Ja, hat die Mantle-Väter (Johan Anderson) lediglich 3 Monate gekostet für den Port auf Mantle. Dazu noch war das Ergebnis alles andere als durchweg überragend. Thief hat nicht so lange gebracht, hatte dafür aber weniger Mehrleistung.

Jetzt erklär mir noch bitte, wieso Publisher ein Spiel bis zu 3 Monate verzögern solten, nur um AMD einen Gefallen zu tun? Der Marktanteil von AMD ist auf 30% fallend. Das heißt man schließt mit solche Nischenlösungen locker 2/3 des Markts aus. Welcher Vollidiot tut so etwas?

Man kann sogar, sobald man die API Doku hat, einen Mantle Treiber schreiben der auf einem Pentium 4 Laufen würde, Mantle ist nur ne API definition, mehr nicht, das kannst du für alles umsetzten. Nur die Frage ist wie Performant das ganze dann ist.

Schau dir doch bitte das Konzept von Mantle an. Der Treiber ist ein großer Bestandteil von Mantle. Ohne einen guten Treiber fällt dir das Konstrukt auseinander.

Nicht wirklich, die Frostbite 3 wird für Dutzende AAA Titel benutzt, fast jedes EA Game benutzt diese Engine, und damit kann auch fast jedes EA Game nativ Mantle.

EA ist AMD-Partner und wurde dafür bezahlt. Trotzdem schränkt es die Zahl an Titel ein.

Ich sehe nicht ein wieso man bei der Cryengine danach den Mantle pfad separat ansprechen müssen soll, damit würde Crytec die eigenen Kunden verärgern. Ausserdem würde ich mal Abwarten bis sich ein Entwickler der auf der Cryengine Entwickel dazu äusserd, vorher sind das Spekulationen ohne Hand und Fuss.

In jedem Entwicklungstool der großen Anbieter musst du Funktionen erst aktivieren und dann im laufenden Entwicklungsprozess stetig anpassen. Bei jedem Effekt muss man vorher die Art auswählen und wie diese sich zu verhalten hat. Die Logik dahinter übernimmt dann die Cryengine selbst bzw. gibt es an den Mantle-Treiber weiter. Der Programmierer muss dennoch viel von Hand machen.

Das ist Zeit und Aufwand und häng von den Interessen des Entwicklers / Publishers zusammen.

Intel hat damit wenig am Hut, wenn die Entwickler Mantle wollen, werden die Graka hersteller nachgeben, liegt ja auch in Ihrem interesse das Games bei Ihnen schnell laufen, da unterschätzt du ganz stark die Macht des Marktes.

Ich hatte diesbezüglich nur jemandem geantwortet. Lies es selbst nach!

Mantle ist keine Engine, Mantle ist nur eine Definition einer Schnittstelle, also Programmiertechnisch sowas:
abstract drawLine(point1, point1);

Das ist die ganze Mantle Definition, der Treiber muss diese FUnktionen nun können und die Engine aufrufen, Die Logik ist aber nicht Teil von Mantle.

Widersprichst du dir hier nicht selbst? Der Treiber ist der Dreh- und Angelpunkt, fertig! Er verwaltet die Befehlsaufrufe und entsprechend die Logik dahinter. Einzig die abstrakten Zwischenschichten fehlen im Vergleich zu DX/OGL. Das ist dann die Verringert des Overhead.

Mantle ist nicht offen blah blah....

So liest sich dein Text, das mag aktuell stimmen, aber die Doku wird wohl früher oder später Freigegeben, dann kann jeder nen Mantle Treiber oder/und ne Mantle fähige Engine schreiben. JEDER.

Bisher können nur AMD-Partner Zugriff auf Mantle erhalten. AMD hält das alles unter enger Kontrolle und gibt bisher nichts frei. Es wird u.U. eine freie Treiberversion geben, aber ein Großteil wird weiterhin properitär sein. Der freie Linux-Treiber für Mantle wird um Welten zurück hinken, wenn es ihn denn überhaupt gibt.

Ich bin gespannt was die Open-Sourcegemeinde dazu sagt. Nvidia bekam seinerzeit für ähnliche Vergehen von Linus Torvalds den Mittelfinger. Zum Glück hat AMD sich bisher "nur geäußert", dass sie planen eine Linuxversion von Mantle in Zukunft zu portieren.

Wenn Mantle nicht offen ist, was ist dann mit PhysX, Cuda? Ach ja, richtig, die sind von NV, da geht das in Ordnung.
Sorry, aber das ist Kinderkram.

Vergleichst du hier nicht Äpfel mit Birnen? Mantle ist geschlossen und AMD hat gelogen. Nvidia interessiert in diesem Zusammenhang nicht.