Herstellerübergreifende low level intermediate language für GPUs? [split] [Archiv]

-/\-CruNcher-/\-

2013-03-09, 01:16:28

Ist vieleicht etwas offtop aber als ich das gelesen habe

"As the PlayStation®4 Graphics API is low level, our Direct3D11 layer for PlayStation®4 is taking care of all the details of interoperating with this API"

Da hab ich mich glatt gefragt ob der AMD Engineer damals auf der Dice Presentation schon an der PS4 arbeitete und deswegen seinen kommentar in die runde warf wir müssen wieder low level gehen in Anbetracht der PS4 würden seine Aussagen von damals ja voll zutreffen ;)

Und die Früchte dieser Arbeit sehen wir Quasi jetzt

Coda

2013-03-09, 13:11:49

Alle Playstations hatten schon immer Low-Level-Zugriff auf die GPU.

del_4901

2013-03-09, 14:02:52

Alle Playstations hatten schon immer Low-Level-Zugriff auf die GPU.Es ist auch besser so, komplizierte Treiber sind total ueberfluessig. Die Zeiten sind vorbei wo man die Entwicker vor sich selbst schuetzen muss.

Coda

2013-03-09, 15:27:47

Sag das mal Microsoft ;)

Spasstiger

2013-03-09, 16:05:37

Coda

2013-03-09, 16:33:58

Es ging um Konsolen. Und ja, da will ich das bitte haben.

Sie können ja trotzdem OpenGL/Direct3D anbieten. Am besten mit vollem Source-Code, damit man sich's selbst adaptieren kann.

del_4901

2013-03-09, 16:34:34

Welcher Entwickler hat ernsthaft Lust, für jede GPU-Architektur einen eigenen Renderer zu schreiben? Bei Exklusivtiteln mag das ja noch eine Option sein, direkt mit dem Befehlssatz der GPU zu arbeiten.
Außerdem könnte ich mir vorstellen, dass die IHVs auf Low-Level-Ebene noch einige Leichen vergaben haben, die mit dem Treiber einfach ausgeblendet werden. Verwechsel mal low-level nicht mit gleich mit Assembler. DirectX ist viele Abstraktionsebenen hoeher als es eigentlich notwendig ist. Ausserdem hat jede bessere Engine mittlerweile eine eigene Abstraktionsebene, da muss man keinen kompletten Renderer mehr schreiben, das ist ne Sache von wenigen PersonenWochen. Und ja ich will das auch haben, sogar auf dem PC.

Coda

2013-03-09, 16:38:19

Und ja ich will das auch haben, sogar auf dem PC.
Und wie läuft dein Zeug dann noch auf zukünftiger Hardware?

Bei der GPU müsste man sich da ja auf eine ISA und ein Command-Buffer-Format einigen, das dann für alle Zeit in Stein gemeiselt ist. Ich glaube nicht, dass das passiert.

del_4901

2013-03-09, 16:45:10

Und wie läuft dein Zeug dann noch auf zukünftiger Hardware?

Bei der GPU müsste man sich da ja auf eine ISA und ein Command-Buffer-Format einigen, das dann für alle Zeit in Stein gemeiselt ist. Ich glaube nicht, dass das passiert.Man muss sich auf eine IL einigen, dann besteht der Treiber nur noch aus dem Backend der daraus asm fuer das final Target generiert. Nach ein paar Jahren wird man die IL dann auch fuer neuere Architekturen erweitern muessen, aber die "alten" Compiler koennen trotzdem fuer die neue Architektur code generieren.

Gipsel

2013-03-09, 17:02:19

Nach ein paar Jahren wird man die IL dann auch fuer neuere Architekturen erweitern muessen, aber die "alten" Compiler koennen trotzdem fuer die neue Architektur code generieren.Andersrum. Die neuen IL-Compiler (der mit einer neuen Hardwaregeneration mit neuem Backend für eine neue ISA kommt) können auch noch den alten Code verstehen und Code für die neue ISA generieren.
Aber ist man dann nicht einfach bei einer vielleicht etwas mehr low level hlsl/glsl-Variante?

del_4901

2013-03-09, 17:14:22

Aber ist man dann nicht einfach bei einer vielleicht etwas mehr low level hlsl/glsl-Variante?Jain, zum einen will ich (mit einem eigenen Frontend) andere Sprachen als HLSL einklinken (Wer mich besser kennt weis welche ;) ). Zum anderen muss die IL geeignet sein um den Commandbuffer beschreiben zu koennen.

Coda

2013-03-09, 17:25:00

Man muss sich auf eine IL einigen, dann besteht der Treiber nur noch aus dem Backend der daraus asm fuer das final Target generiert. Nach ein paar Jahren wird man die IL dann auch fuer neuere Architekturen erweitern muessen, aber die "alten" Compiler koennen trotzdem fuer die neue Architektur code generieren.
Aber D3D hat doch intern eine IL? Zumindest für Shader.

Was doch viel eher das Problem ist, ist dass du Pipeline-Bubbles etc. hast, weil du die Auslastung und DMA-Transfers nicht selbst kontrolieren kannst.

Oder versteh ich dich gerade falsch und du willst eine IL, die den Command-Buffer schreibt? Back to the Direct3D-3-Roots? ;)

del_4901

2013-03-09, 17:27:25

Aber D3D hat doch intern eine IL? Zumindest für Shader.Ja intern, das ist genau das Problem. :) Und wie geasgt die muss dann auch fuer den Commandbuffer herhalten oder man nimmt 2 getrennte (ist aber eigentlich nicht notwendig).

Was doch viel eher das Problem ist, ist dass du Pipeline-Bubbles etc. hast, weil du die Auslastung und DMA-Transfers nicht selbst kontrolieren kannst.Da muss man sich dann selber drum kuemmern.

Oder versteh ich dich gerade falsch und du willst eine IL, die den Command-Buffer schreibt? Back to the Direct3D-3-Roots? ;)
Ja, nur besser.

Coda

2013-03-09, 18:01:29

del_4901

2013-03-09, 18:04:16

Ich seh ehrlich gesagt kein großes Problem mit HLSL. Ob ich jetzt HLSL als Abstraktion habe oder eine Assembly-IL macht mir nichts aus.

Das könnte man ja auch bei der Sprache für Command-Buffer genauso halten.HLSL ist zu high level. Man braucht eine low level abstraktion wenn man flexibel(zukunftsweisend) bleiben moechte. (LLVM-IL artig)

Demirug

2013-03-09, 19:35:00

Ja intern, das ist genau das Problem. :)
Du lässt dich doch nicht etwas von der Signature im Shader abhalten? Als mir das was der HLSL Compiler erzeugt hat (Constant Buffer Layout) nicht gefallen hat habe ich mir halt einen Postprozessor gebaut welcher die Shader nachträglich manipuliert hat.
Ja, nur besser.
Halte ich beim PC für nicht ganz ungefährlich. Ist ja nicht gerade so das dort alle GPUs das gleiche Leistungsprofil haben.
HLSL ist zu high level. Man braucht eine low level abstraktion wenn man flexibel(zukunftsweisend) bleiben moechte. (LLVM-IL artig)
DX-IL geht doch in die Richtung. Ist nur im Gegensatz zu LLVM Vektor orientierter.

Es gibt btw auch die gegenteilige Meinung. Anhänger dieser Richtung führen auf das durch das runterbrechen auf eine IL zu viel von der eigentlichen Semantik verloren geht und dadurch Optimierungen auf zukünftige bessere Hardware erschwert wird. Ich muss wohl nicht sagen das diese Gruppe den OpenGL Ansatz mit GLSL für den richtigen hält.

del_4901

2013-03-09, 19:42:24

Halte ich beim PC für nicht ganz ungefährlich. Ist ja nicht gerade so das dort alle GPUs das gleiche Leistungsprofil haben. Wo soll das zu Problemen fuehren, wenn man abstrakte Commandbuffer schreibt die eine IL beinhalten und vor der Execution auf die hardware Commandbuffer und ISA runtergebrochen werden? Ich seh nur nicht triviale Synchronisierungprobleme aber da muss man eben etwas Oversynchronisieren, das machen aktuelle Treiber eh schon.

DX-IL geht doch in die Richtung. Ist nur im Gegensatz zu LLVM Vektor orientierter.Welche IL ist eigentlich egal, solange sie offen ist.

Es gibt btw auch die gegenteilige Meinung. Anhänger dieser Richtung führen auf das durch das runterbrechen auf eine IL zu viel von der eigentlichen Semantik verloren geht und dadurch Optimierungen auf zukünftige bessere Hardware erschwert wird. Ich muss wohl nicht sagen das diese Gruppe den OpenGL Ansatz mit GLSL für den richtigen hält.Naja, diese Gruppe muss erstmal beweisen, dass Sie was zusammen gebaut bekommen. Ich seh das eher andersrum.

Demirug

2013-03-09, 19:49:36

Wo soll das zu Problemen fuehren, wenn man abstrakte Commandbuffer schreibt die eine IL beinhalten und vor der Execution auf die ISA runtergebrochen werden?

Zu dem gleichen Problemen das wir jetzt auch schon haben nur noch in verschäfter Form. Man programmiert Commandosequezen die einer Hardware gefallen und einer anderen nicht. Entsprechend werden dann die Treiber wieder vollgestopft mit Routinen welche solchen Sequenzen erkennen und umändern.

Naja, diese Gruppe muss erstmal beweisen, dass Sie was zusammen gebaut bekommen. Ich seh das eher andersrum.

Ich bin auch kein Anhänger davon muss mich nur leider mit den Folgen rumschlagen.

del_4901

2013-03-09, 19:55:12

Zu dem gleichen Problemen das wir jetzt auch schon haben nur noch in verschäfter Form. Man programmiert Commandosequezen die einer Hardware gefallen und einer anderen nicht. Entsprechend werden dann die Treiber wieder vollgestopft mit Routinen welche solchen Sequenzen erkennen und umändern.Das ist richtig und sogar gewollt. Als "neuen Treiber" hat man neben dem Backend noch einen Optimizer der die Codesequenzen in der IL optimiert oder optional auch in eine proprietäre IL transformiert. Die Komplexitaet eines solchen Systems sollte kleiner sein als bei heutigen Treibern. Man wechselt einfach den Optimizer aus, oder verwendet jeweils nur ein Subset der moeglichen Code-Transformationen.

Coda

2013-03-10, 13:08:11

Theoretisch ist es wohl schon besser, wenn der Treiber die Hochsprache bekommt. Das scheitert in der Praxis nur am hohen Aufwand einen ordentlichen Compiler zu schreiben ;)

Gipsel

2013-03-10, 14:36:59

Theoretisch ist es wohl schon besser, wenn der Treiber die Hochsprache bekommt. Das scheitert in der Praxis nur am hohen Aufwand einen ordentlichen Compiler zu schreiben ;)
Das Problem ist auch, daß die IL sich eventuell zu nah an der Hardware orientiert und wirklich für spätere Generationen suboptimal wird. Das kann man ein wenig bei AMD beobachten. Deren IL ist praktisch nur das etwas aufgebohrte DX-ASM. Für die VLIW-Architekturen war das praktisch perfekt, die .xyzw Komponenten und swizzles mappten praktisch direkt auf die Fähigkeiten der zugrundeliegenden Hardware, da mußte "nur" ein Optimizer drübergejagt werden, der die Port-Beschränkungen der Hardware berücksichtigt sowie mehrere unvollständig benutzte Vektoren zusammenfaßte (und noch eine fünfte Komponente in die VLIW-Anweisungen gequetscht hat). Aber für die aktuelle GCN-Generation ist das zunehmend unbequem. Wenn ich die Wahl hätte, würde ich da lieber direkt GCN-Assembly schreiben. Oder zumindest eine sehr nahe Abwandlung davon (virtuelles Registerset wäre nett, ein leightweight Optimierer müßte dann nur die Registernutzung optimieren und z.B. die waitcounter einfügen, damit man da nicht selber mitzählen muß). Es ist meiner Meinung nach ziemlich schwierig, solche Features wie die Skalareinheit (und auch die skalaren Loads) in einer allgemeinen IL effektiv zu exponieren.
Also entweder low level und hardwareorientiert (schränkt die herstellerübergreifende Kompatibilität ein) oder man abstrahiert stärker von der Hardware, was dann praktisch keine wirklich wesentlichen Vorteile mehr gegenüber HLSL hat (was kann man da nicht ausdrücken?).

Das größere Problem sind vermutlich sowieso die Commandbuffer, da hier die Hardwareunterschiede vermutlich noch größer sind und sowas in der Art einer low level IL somit noch schwerer realisierbar ist.

Coda

2013-03-10, 15:27:11

Seh ich das Problem jetzt nicht so sehr. Man kann die VLIW-Form doch ziemlich einfach in SSA umwandeln und dann nen anderen Optimierer drüberlaufen lassen (basierend auf LLVM z.B.)

del_4901

2013-03-10, 17:12:57

Das Problem ist auch, daß die IL sich eventuell zu nah an der Hardware orientiert und wirklich für spätere Generationen suboptimal wird. Dann wird die IL halt erweitert, ich wuerde mir darueber erstmal keinen Kopf zerbrechen. Erfahrungsgemaess ist es keine gute Idee irgendwelche Probleme in der Informatik vorherzusehen. Man sollte einfach nur die Probleme loesen die man hat.

Das größere Problem sind vermutlich sowieso die Commandbuffer, da hier die Hardwareunterschiede vermutlich noch größer sind und sowas in der Art einer low level IL somit noch schwerer realisierbar ist.Hier sehe ich auch nicht so ein grosses Problem. Das komplizierteste an der Sache ist noch das Speicher und Ressourcen Management. Da braucht man irgendwelche Flags wo der Programmierer angeben kann das seine Ressource im Fast Mem landet oder fuer CPU Zugriff optimiert werden soll.

][immy

2013-03-10, 19:03:49

Hardware-nähe ist auf Dauer aber ziemlich teuer. Auf diese weise hat man zum einen ständig mit Inkompatibilitäten zu kämpfen und zum anderen sind mit jeder neuen hardware-generation wieder weitere und vor allem neue optimuerungen notwendig. Das macht die Sache auf Dauer immer komplizierter und vor allem teuer. Alte algorythem mus man schließlich immer wieder neu testen. Eine allgemeine im auf die man später mit einem Framework dazwischen wäre schon wesentlich besser.

Klar kann man so nicht immer effizient 100% rausholen, aber besonders komplexe Dinge lassen sich einfacher erstellen. Wer will sich schon noch um Probleme kümmern die man vorher schon 100 mal gelöst hat.

OBrian

2013-03-11, 13:28:24

Wichtig ist doch erstmal nur, daß es für die Entwickler eine definierte Schnittstelle gibt, auf der sie aufbauen können. Wie hardwarenah oder -fern die ist, spielt im Grunde keine Rolle. Das wird davon bestimmt, wie unterschiedliche die Hardware der Zielplattform ist. Bei der Konsole ist die Hardware immer exakt gleich, also kann man nah an die Hardware gehen. Beim PC muß man weiter wegbleiben, um alle möglichen Kombinationen unter einen Hut zu bekommen.

del_4901

2013-03-11, 14:52:23

Wenn es hart auf Hart kommt, dann wuerde ich auch mit jehweils einer API fuer AMD, Nvidia und Intel leben. Eine Abstraktionschicht hat eh jedes game.

Gipsel

2013-03-11, 15:17:45

Du willst wirklich diese "can of worms" öffnen?

PS:
Was wäre eigentlich die deutsche Entsprechung für "can of worms"? Büchse der Pandora (Pandora's box) paßt ja nicht wirklich.

del_4901

2013-03-11, 15:48:47

Du willst wirklich diese "can of worms" öffnen?
Ja ;)
Man kann dann ja immernoch eine gemeinsame (offene) Api drueberbauen.

Coda

2013-03-11, 16:20:53

Wieso sollte eine Abstraktion von beispielsweise NVIDIA nur für ihre GPUs besser sein als Direct3D?

del_4901

2013-03-11, 16:42:37

Wieso sollte eine Abstraktion von beispielsweise NVIDIA nur für ihre GPUs besser sein als Direct3D?
In D3D hat man nur implizites Speichermanagement. Das macht das Streaming aufwaendiger/ineffizient. Ausserdem haelt D3D nur die Entwicklung auf, es gibt immernoch keine PRTs. In Direct3d wird auch total oversynchronisiert und geflushed. Der Treiber/D3D kann es einfach nicht besser wissen als das Game wann Resourchen wie verwendet werden.

Coda

2013-03-11, 16:52:05

Ich seh da nichts was man nicht Allgemein lösen könnte, evtl. mit einem Extension-Mechanismus.

Sprich: OpenGL :D

del_4901

2013-03-11, 16:57:31

Ich seh da nichts was man nicht Allgemein lösen könnte, evtl. mit einem Extension-Mechanismus.
Sprich: OpenGL :D Extensions sind ja nicht nur Boese. Das Problem mit OpenGL ist eher das die Khronos Gruppe sich nicht ausmehrt, weil da viele inkompetente Leute im Gremium sitzen, die APi grundlos kompliziert halten wollen.

Ailuros

2013-03-11, 17:08:08

Extensions sind ja nicht nur Boese. Das Problem mit OpenGL ist eher das die Khronos Gruppe sich nicht ausmehrt, weil da viele inkompetente Leute im Gremium sitzen, die APi grundlos kompliziert halten wollen.

Ich glaub Demirug erwaehnte mal dass OGL_ES bis zu einem gewissem Zeitpunkt als um einiges "aufgeraeumter" erschien als OGL selber; keine Ahnung ob es so geblieben ist oder ob es sich auch beim letzteren zum schlechteren geaendert hat, aber waeren es nicht mehr oder weniger die gleichen Leute bei Khronos die solche APIs definieren oder gibt es fuer jegliches API andere?

del_4901

2013-03-11, 17:10:38

Ich glaub Demirug erwaehnte mal dass OGL_ES bis zu einem gewissem Zeitpunkt als um einiges "aufgeraeumter" erschien als OGL selber; keine Ahnung ob es so geblieben ist oder ob es sich auch beim letzteren zum schlechteren geaendert hat, aber waeren es nicht mehr oder weniger die gleichen Leute bei Khronos die solche APIs definieren oder gibt es fuer jegliches API andere?
Die machen die gleichen Fehler mit ES wie mit GL. Am Prozess hat sich NICHTS geaendert.

Coda

2013-03-11, 18:53:08

OpenGL 4.3 ohne Legacy-Kram sieht doch sauber aus?

Ailuros

2013-03-11, 19:10:17

Die machen die gleichen Fehler mit ES wie mit GL. Am Prozess hat sich NICHTS geaendert.

Weil sich die beteiligten IHVs auch nicht geaendert haben?

Demirug

2013-03-11, 19:45:29

Wenn es hart auf Hart kommt, dann wuerde ich auch mit jehweils einer API fuer AMD, Nvidia und Intel leben. Eine Abstraktionschicht hat eh jedes game.

Laut einen Treiberentwickler von AMD kommt man auf dem PC nicht viel weiter runter als D3D ohne es dann gleich per Chip Generation zu machen.

In D3D hat man nur implizites Speichermanagement. Das macht das Streaming aufwaendiger/ineffizient. Ausserdem haelt D3D nur die Entwicklung auf, es gibt immernoch keine PRTs. In Direct3d wird auch total oversynchronisiert und geflushed. Der Treiber/D3D kann es einfach nicht besser wissen als das Game wann Resourchen wie verwendet werden.

Explizites Speichermanagement ist schwierig zu realisieren wenn sich mehrer Prozesses um die Resource GPU schlagen dürfen. Zudem wollen sich auf dem PC viele Entwickler mit dem Problem der unterschiedlichen Mengen von unterschiedlichen Speichern gar nicht rumschlagen. Den meisten geht es darum schnell zu portieren und den Testaufwand auf ein Minimum zu reduzieren. Man will für "den PC" entwickeln und nicht für viele verschiedene Konfigurationen.

Extensions sind ja nicht nur Boese. Das Problem mit OpenGL ist eher das die Khronos Gruppe sich nicht ausmehrt, weil da viele inkompetente Leute im Gremium sitzen, die APi grundlos kompliziert halten wollen.

Das Problem ist der heilige Gral der Kompatibilität um jeden Preis welcher einen harten Schnitt verhindert.

Ich glaub Demirug erwaehnte mal dass OGL_ES bis zu einem gewissem Zeitpunkt als um einiges "aufgeraeumter" erschien als OGL selber; keine Ahnung ob es so geblieben ist oder ob es sich auch beim letzteren zum schlechteren geaendert hat, aber waeren es nicht mehr oder weniger die gleichen Leute bei Khronos die solche APIs definieren oder gibt es fuer jegliches API andere?

Bei ES war man bereit mit 2.0 einfach den ganzen Fixed Funktion kremple rauszuwerfen. Damit war es schon besser als Desktop GL. Aber das Objektmodel von OpenGL welche nach wie vor nicht optimal ist hat man nicht wirklich konsequent geändert.

Weil sich die beteiligten IHVs auch nicht geaendert haben?

Wenn es um grundsätzliche Sachen geht haben die IHVs dort nicht viel zu melden.

Coda

2013-03-11, 19:47:24

Wenn es um grundsätzliche Sachen geht haben die IHVs dort nicht viel zu melden.
Ernsthaft? Wow :ugly:

Ailuros

2013-03-11, 19:57:57

Wenn es um grundsätzliche Sachen geht haben die IHVs dort nicht viel zu melden.

Ja pfui Teufel....:eek:

del_4901

2013-03-11, 20:15:38

Laut einen Treiberentwickler von AMD kommt man auf dem PC nicht viel weiter runter als D3D ohne es dann gleich per Chip Generation zu machen.Wer war das?

Explizites Speichermanagement ist schwierig zu realisieren wenn sich mehrer Prozesses um die Resource GPU schlagen dürfen. Zudem wollen sich auf dem PC viele Entwickler mit dem Problem der unterschiedlichen Mengen von unterschiedlichen Speichern gar nicht rumschlagen. Den meisten geht es darum schnell zu portieren und den Testaufwand auf ein Minimum zu reduzieren. Man will für "den PC" entwickeln und nicht für viele verschiedene Konfigurationen.Man hat schon noch sowas wie virtuelle Adressen, man arbeitet aber direkt auf der (H)MMU und mapt sich seine Ressourcen selber zusammen (z.B. fuer PRT). Es soll ja auch nur fuer Profis und solche die sich gerne aus Threads nen Strick drehen wollen gedacht sein. Der Rest nimmt entweder OGL/D3D oder einen offenen Abstraktions Layer.

Demirug

2013-03-11, 20:17:14

Ernsthaft? Wow :ugly:

In den Arbeitsgruppen sitzen systembedingt in der Regel mehr ISV als IHV was im Zweifel dann immer zu Bestandschutz führt. Als IHV hat man da keine Argumente dagegen. Den man muss ja mit neuer Hardware auch Kompatibilität zu D3D bieten . Wenn das geht darf auch in seiner jetzigen Form OpenGL kein Problem sein.

Was von den IHVs in der Regel kommt sind eben neue Extensions. ISV können da schlecht was vorschlagen weil sie ja gar nicht wissen was die neue Hardware kann.

Beide Parteien sind dann in der Regel involviert wenn es darum geht die Extensions zu vereinheitlichen. Wobei das dann tendenziell auch eher die IHVs unter sich ausmachen.

Demirug

2013-03-11, 20:24:15

Wer war das?

Keine Ahnung. Kann mir Namen eher schlecht merken wenn ich Leute nur ein oder zweimal sehe. Das war auf einer Konferenz mit Leuten von EA und AMD.

Man hat schon noch sowas wie virtuelle Adressen, man arbeitet aber direkt auf der (H)MMU und mapt sich seine Ressourcen selber zusammen (z.B. fuer PRT). Es soll ja auch nur fuer Profis und solche die sich gerne aus Threads nen Strick drehen wollen gedacht sein. Der Rest nimmt entweder OGL/D3D oder einen offenen Abstraktions Layer.

Wenn man bedenkt wie viele Leute sich mit der D3D Speicherverwaltung schon selbst in den Fuss geschossen haben und nur überlebt haben weil es der Treiber dann wieder hingebogen hat bleiben nicht mehr so viele Kunde für eine solche API. AMD wollte ja mal sowas machen und hat auch bei Entwicklern angefragt. Das Feedback scheint es wohl nicht gerechtfertigt zu haben da ein Team dran zu setzen.

][immy

2013-03-11, 23:14:37

Wer war das?

Man hat schon noch sowas wie virtuelle Adressen, man arbeitet aber direkt auf der (H)MMU und mapt sich seine Ressourcen selber zusammen (z.B. fuer PRT). Es soll ja auch nur fuer Profis und solche die sich gerne aus Threads nen Strick drehen wollen gedacht sein. Der Rest nimmt entweder OGL/D3D oder einen offenen Abstraktions Layer.
yey, am besten gleich zurück zur assembler-programmierung, damit wären wir heute ... ja wo genau? effizient, ja (eventuell) aber schnelle entwicklung ist damit nicht möglich.

kein entwickler will sich heute wirklich mehr um jede kleinigkeit selbst kümmern. es gibt frameworks & co um die entwicklungsprozesse zu beschleunigen. man muss ja schließlich nicht das rad immerwieder neu erfinden.

ich kann verstehen wenn man low-level entwicklen will, irgendwer muss auch die treiber schreiben, aber in zukunft low-level programmierung bei spielen einzusetzen ist beinahe wahnwitzig was die entwicklungskosten angeht. die kosten können ja schließlich nicht endlos steigen.

eine engine für jede gpu schreiben, da hat man sehr viel zu tun. für einzelne features ist das ja noch durchaus vertretbar aber alles ist einfach zu viel.

bei konsolen mag das ja durchaus anders sein, aber im grunde genommen ist hier das gleiche problem. die featuresets sind so groß inzwischen, das erst mal über jahre eine entsprechende engine entstehen muss.

ich bin da in meiner Ansicht vielleicht ein wenig extrem, aber Kompatibilität mag vielleicht nicht alles sein, fördert aber die Entwicklung, während low-level Programmierung die Entwicklung eher ausbremst. Zudem hat man so die Chance etwas fertig zu stellen und über spätere Hardware- und Treiberanpassungen das gesamte auch noch in Zukunft zu optimieren.

del_4901

2013-03-11, 23:24:00

[immy;9688755']eine engine für jede gpu schreiben, da hat man sehr viel zu tun. für einzelne features ist das ja noch durchaus vertretbar aber alles ist einfach zu viel.
Wenn man ne neue Engine fuer jede GPU/Api/Platform schreiben muss, dann hat man was falsch gemacht.

[immy;9688755']ich bin da in meiner Ansicht vielleicht ein wenig extrem, aber Kompatibilität mag vielleicht nicht alles sein, fördert aber die Entwicklung, während low-level Programmierung die Entwicklung eher ausbremst. Zudem hat man so die Chance etwas fertig zu stellen und über spätere Hardware- und Treiberanpassungen das gesamte auch noch in Zukunft zu optimieren.Das sehe ich genau andersrum.

][immy

2013-03-11, 23:37:35

Wenn man ne neue Engine fuer jede GPU/Api/Platform schreiben muss, dann hat man was falsch gemacht.

Das sehe ich genau andersrum.

nunja, das ist ungefähr so
der eine baut rein rad
der andere ein zahnrad
der nächste einen motor
und irgendjemand kommt au die idee das ganze zu verbinden zu einer vision .. .das auto ist geboren.

was ich damit sagen will, wenn man immer nur auf der untersten ebene bleibt, schließt man die, die sich dort vielleicht nicht auskennen aber visionen und ideen haben aus. auf diese weise ist der fortschritt nur in der hand von wenigen. keiner kann auf den fortschritten von anderen aufsetzen (besonders weil diese mit der zeit inkompatibel werden). große frameworks (z.b. direct3d sehe ich jetzt mal als ein solches framework) erweitern so einfach den ideenpool.

auf diese weise kann man über den treiber eine gewisse effizienz erwirken und den ideenpool über high-level und kompatibilität erweitern.

del_4901

2013-03-11, 23:45:08

[immy;9688780']was ich damit sagen will, wenn man immer nur auf der untersten ebene bleibt, schließt man die, die sich dort vielleicht nicht auskennen aber visionen und ideen haben aus. auf diese weise ist der fortschritt nur in der hand von wenigen. keiner kann auf den fortschritten von anderen aufsetzen (besonders weil diese mit der zeit inkompatibel werden). große frameworks (z.b. direct3d sehe ich jetzt mal als ein solches framework) erweitern so einfach den ideenpool.Das schliesst sich nicht aus. Man kann auf Basis mehrerer Hersteller spezifischen APIs ein D3D, OGL oder aehnliches zusammenbauen. Das ist sogar einfacher als einen D3D <-> OGL Wrapper zu schreiben. Und wenn Nachfrage besteht, werden sich schon Leute finden, die genau das bereitstellen. Stellt euch das mal vor eine offene API fuer alle Betriebssysteme und Platformen... Ist das kein Fortschritt?

[immy;9688780']auf diese weise kann man über den treiber eine gewisse effizienz erwirken und den ideenpool über high-level und kompatibilität erweitern.Das ist ein Irrglaube.

-/\-CruNcher-/\-

2013-03-12, 16:05:06

Stellt euch das mal vor eine offene API fuer alle Betriebssysteme und Platformen... Ist das kein Fortschritt?

Hab ich was verpasst war das nicht schon immer OGL ;) ?

Ich glaube nicht das D3D eine weite Zukunft mehr hat, ich glaube eh das Microsoft in einer Kriese steckt und das diese größer wird für sie über die nächsten Jahre.

Spiele als Alleinstellungsmerkmal des OS brechen vollkommen weg das wird ein heftiger schlag der viel weiter geht als ihr denkt (die Generationenbindung geht ihnen langsam verloren), die Anfänge sehen wir doch schon seit längerem.
Sie werden sich auf ihre Konsole konzentrieren das ist das einzig vernünftige die Resourcen werden neu geordnet nur die Frage was wird hier lange überleben vor allem in neuen Märkten und Entwicklerresourcen bedingt Entwickler die nur 1 Platform bedienen müssen werden schneller voran kommen (sleeker) sein als die die 3 verschiedene Platformen bedienen wollen oder müssen.

del_4901

2013-03-12, 17:36:50

Hab ich was verpasst war das nicht schon immer OGL ;) ? Gibt es nicht auf allen Platformen und es gibt nicht immer source von daher sind die Anpassungsmoeglichkeiten eher eingeschraenkt.

del_4901

2013-09-25, 23:07:56

„Mantel“ für ausgenutzte High-End-Hardware
AMD will Konsolen- und PC-Entwicklung vereinfachen

http://www.computerbase.de/news/2013-09/amd-will-konsolen-und-pc-entwicklung-vereinfachen/

Mit AMDs Mantle APi ist an der Zeit diesen Thread wiederzubeleben.

RLZ

2013-09-25, 23:35:59

Gibt es abgesehen von dem Marketingmaterial schon genauere Infos drüber?

samm

2013-09-26, 00:43:28

Derzeit im Stream: Im Dezember kommt ein Patch für BF4, welches dann auf Radeons auf Mantle statt DX läuft. Zusammen mit Dice/EA entwickelt. An Marketing-Zahlen gab's noch "9x mehr Drawcalls pro Sekunde im Vergleich mit andern APIs"

Am AMD Dev. Summit 13 soll's Details geben.

M4xw0lf

2013-09-26, 08:46:19

Mit AMDs Mantle APi ist an der Zeit diesen Thread wiederzubeleben.
Da hier in dem Thread ja schon geballte Entwicklerkompetenz sitzt: wie schätzt ihr das Potential von Mantle ein? Ende von DirectX? nice to have, aber nicht revolutionär? Randnotiz?

Knuddelbearli

2013-09-26, 09:09:09

kommt drauf an wie NV und oder Intel damit umgehen ( wenn Intel mitgeht ist es egal was NV macht und umgekehrt )
und natürlich obs auch auf Linux 1a läuft, wovon man aktuell aber ausgehen darf

Cubitus

2013-09-26, 09:12:34

Da hier in dem Thread ja schon geballte Entwicklerkompetenz sitzt: wie schätzt ihr das Potential von Mantle ein? Ende von DirectX? nice to have, aber nicht revolutionär? Randnotiz?

Wäre auch meine Frage. Ich bin ziemlich skeptisch, auf so Präsentationen wird immer viel geblubbert. Die Marketing-Leute müssen ja auch Ihre Ideen wirklich nie selbst umsetzten ;D

Hugo78

2013-09-26, 09:50:42

Mir wird langsam klar, warum Nvidia nicht mehr in DX11.1 investiert hat bei Kepler, wo DX überflüssig wird, mit Valves und AMDs aktuellen Bemühungen.

Microsoft muss es grade bitter aufstoßen, dass sie mit der Wahl von AMDs APU für die XBOx One, einen wichtigen Sargnagel für den Untergang von D3D liefern.
Ohne D3D Zwang, gibt es keine Notwenigkeit mehr sich Windows zukaufen.

Läuft in Zukunft alles auf Konsolen (Wo Sony besser aufgestellt ist) und SteamOS Linux PCs/Boxes.

del_4901

2013-09-26, 10:08:23

fondness

2013-09-26, 10:20:15

Wenn man sich ansieht welchen Aufwand die IHVs in Ihren D3D Treibern betreiben um die Performance zu verbessern oder um vermeintliche Bugs auszumerzen, dann ist eine Low Level API längst überfällig.

Die Frage ist höchstens wie viele Entwickler das dann auch beherrschen. :D
Aber da ohnehin fast alle Blockbuster auch für Konsolen kommen ist das für AMD natürlich eine einmalige Chance.

/Edit: Hier ein relativ ausführlicher Artiekl von PCGH: http://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Specials/AMD-Low-Level-API-Mantle-Battlefield-4-1090085/

Undertaker

2013-09-26, 10:34:28

Wenn man sich ansieht welchen Aufwand die IHVs in Ihren D3D Treibern betreiben um die Performance zu verbessern oder um vermeintliche Bugs auszumerzen, dann ist eine Low Level API längst überfällig.

Wie sieht es denn mit den Entwicklungsressourcen aus? Wenn Nvidia und ggf. sogar Intel auch eigene Low-Level-APIs bringen würden, wäre der Aufwand nicht immens höher als eine einzige, aber weniger optimierte DirectX-Version? Zumal letztere doch ohnehin auf Jahre hinaus weiter vorhanden sein muss?

Iruwen

2013-09-26, 14:52:40

Geht der Trend nicht eher in Richtung Abstraktion (siehe z.B. AMDs Bolt), wer will in so einem heterogenen Umfeld wirklich hardwarenah programmieren bzw. wer hat die Ressourcen dazu wenn er nicht wie die Gaming Evolved / TWIMTBP Partner direkt unterstützt wird? Das sprengt doch jedes Budget. Bei den Konsolen ist das einfach, beim PC ja aber eher nicht. Ist ja nicht nur AMD/NV/Intel sondern auch noch deren alte Hardware die für viele Jahre in Umlauf bleibt.

Nightspider

2013-09-26, 15:02:27

Iruwen

2013-09-26, 15:54:56

Sie pushen zumindest mit neuen DX Versionen neue Windows-Versionen und halten die Leute von Linux fern.

Hugo78

2013-09-26, 22:53:09

Welchen Nachteil hätte denn der Niedergang von D3D für MS?
Ist ja nicht so als wenn MS damit Geld verdient.

Natürlich, D3D ist das Verkaufsargument für Windows bei PC-Spielern.
Ansonst könnte man auch einfach Ubuntu installieren.

Cubitus

2013-09-26, 23:23:53

Zudem muss man glaube ich für das Nutzen diverser Komponenten, wie z.b dlls, auch Lizens-Geld bezahlen.
Denke M$ verdient mit D3D schon ein nettes Sümmchen :D

Demirug

2013-09-26, 23:25:56

Zudem muss man glaube ich für das Nutzen diverser Komponenten, wie z.b dlls, auch Lizens-Geld bezahlen.
Denke M$ verdient mit D3D schon ein nettes Sümmchen :D

Wer erzählt den so einen Blödsinn? Man muss für nichts was Teil der Windows API ist irgendwas bezahlen. Dafür bezahlen die Endkunden doch ihre Windows Lizenz.

Cubitus

2013-09-27, 00:04:24

Wer erzählt den so einen Blödsinn? Man muss für nichts was Teil der Windows API ist irgendwas bezahlen. Dafür bezahlen die Endkunden doch ihre Windows Lizenz.

Ich habe vor Jahren mal von Gestorn gehört das er für eine D3D Komponente bezahlen musste. Deswegen diese Vermutung. Aber 2 Minuten Google hätten es auch getan. Hast natürlich Recht :redface:

StefanV

2013-09-27, 04:06:03

AMD wollte ja mal sowas machen und hat auch bei Entwicklern angefragt. Das Feedback scheint es wohl nicht gerechtfertigt zu haben da ein Team dran zu setzen.
Schaut wohl so aus, als ob AMD das doch gemacht hat, irgendwie :D :D

OK, würde eher davon ausgehen, dass (z.B.) Dice (ev. auch Chris Roberts) 'nen bisserl druck auf AMD gemacht haben, das endlich mal fertig zu machen...

Demirug

2013-09-27, 08:59:06

Schaut wohl so aus, als ob AMD das doch gemacht hat, irgendwie :D :D

OK, würde eher davon ausgehen, dass (z.B.) Dice (ev. auch Chris Roberts) 'nen bisserl druck auf AMD gemacht haben, das endlich mal fertig zu machen...

Das ganze ist doch jetzt ein Abfallprodukt dessen was sowieso für die Konsolen gemacht werden musste.Ich weiß das DICE es schon damals gerne gesehen hätte also hat sich an der Position nichts geändert in der Zeit.