News Vulkan-API: „Lots of rules and no mercy.“

[DefconDev]

Wichtig ist dass Vulkan voran getrieben wird. Konkurrenz belebt das Geschäft. Directx11 war lange genug an der "Macht". Wenn ich mir anschaue was teilweise die AMD-CPUs davon profitieren, bleibt der Eindruck einfach erhalten das MS und Intel bewusst AMD jahrelang außen vor gelassen haben.

 

[Jyk]

Die Frage ist also:
Werden die Entwickler/Studios bereit sein, diesen Mehraufwand zu betreiben?
Oder bleiben sie doch lieber bei schneller und günstiger zu entwickelnden, weniger optimierten Spielen, die entweder weiter auf die alten APIs setzen, oder zwar auf die neuen APIs, aber deren Vorteile/Möglichkeiten nicht wirklich ausnutzen?

Mal eine ganz gemeine Frage dazu, haben die Studios überhaupt diese fähigen Entwickler auf Halde um sowas stemmen zu können? Das müssten ja denn sehr spezialisierte Entwickler sein die dementsprechend auch Bezahlt werden wollen. Wenn ich alleine die Kosten der heutigen AAA Titel wie GTA sehe wird das interessant werden. Nicht das Hardwarenahe Entwicklung wieder zugunsten einfacher Programmierung fallen gelassen wird. Aber ab 2017 wird es sich denn zeigen was daraus wird und wer welche Marktanteile sich sichern wird.

 

[nille02]

Also man arbeitet gerade daran Vulkan auf D11-Niveau betreiben zu können?
Wie soll das dann eine Konkurrenz zu D12 werden?

Da geht es um die Ports. Die ersten Ports sind versuche D3D11 Code auf Vulkan zu bringen.

 

[kisser]

Das ist bei DX12 aber genauso.

 

[wahlmeister]

Es wäre wirklich sehr zu begrüssen wenn Vulkan DX völlig verdrängen könnte. DX hätte von vorherein niemals diese Macht erreichen dürfen da es properitäter Mist ist und die Entwicklung lange genug gebremst hat. OpenGL/Vulkan/Metal sind das was gepusht werden muss. Das ist wichtig für cross platform Titel und würde die Portierung oder gar native Entwicklung für Linux und OS X/iOS massiv vorwärts bringen.

 

[UltraWurst]

Mal eine ganz gemeine Frage dazu, haben die Studios überhaupt diese fähigen Entwickler auf Halde um sowas stemmen zu können? Das müssten ja denn sehr spezialisierte Entwickler sein die dementsprechend auch Bezahlt werden wollen. Wenn ich alleine die Kosten der heutigen AAA Titel wie GTA sehe wird das interessant werden.

Das wird gerade bei AAA-Titeln an den Kosten kaum etwas ändern. Da geht ja das meiste der Kohle dafür drauf, die ganzen 3D-Artists zu bezahlen, die die riesigen Open-World-Levels, Outfits, Fahrzeuge, etc. entwerfen ... oder Lizenzen, Marketing, Musik, Schauspieler, etc.

Allerdings zur ersten Frage:
Nein bzw. kaum. Entwickler, die effizientes, Hardware-nahes Coding wirklich drauf haben, dürften eher rar sein.
Das ist sehr anspruchsvoll und wurde ja nun lange Zeit (zumindest beim Thema Gaming) eher stiefmütterlich behandelt.
Wenn's dann mal jemanden gibt, der in der Richtung wirklich was drauf hat, ist es gleich ein "Guru" (siehe z.B. John Carmack).

Ist auch in anderen Software-Branchen ähnlich.
Wenn ich z.B. an Audio-Software denke, dann bauen da >90% der Plugins auf sehr einfachen, alt-bekannten Konzepten auf. Die allerwenigsten Entwickler betreiben tatsächliches Engineering und erschaffen etwas technisch besonderes.

 

[nille02]

Das ist bei DX12 aber genauso.

Hat ja auch niemand was anders gesagt. Hier ist man beim Marketing nur etwas cleverer. Wer die Benchmarks zu Talos gesehen hat, ist von Vulkan eher abgeschreckt. Ganz gleich was sie noch bringen.

Ergänzung (5. April 2016)

Es wäre wirklich sehr zu begrüssen wenn Vulkan DX völlig verdrängen könnte.

Warum? Dann stagniert das andere. Die Konkurrenz ist gut. Bedauerlicher weise stellen sich die OGL Boy nur hin und jammern über D3D, anstelle ihre eigene Baustelle voran zu bringen.

DX hätte von vorherein niemals diese Macht erreichen dürfen

Hat es aber. Lag aber an der besseren Konkurrenz.

da es properitäter Mist

Die API ist bekannt und wurde ja schon mehrfach neu Implementiert. Man schaue nur mal auf Wine oder Gallium3D. Erstere versucht es über OGL zu Implementieren was aber eher schlecht funktioniert.

ist und die Entwicklung lange genug gebremst hat.

Wo hat denn D3D die Konkurrenz gebremst? Schlechte Dokumentationen, unterschiedliche Implementierungen, schlechte Tools, etc, sind alles probleme von OGL(ES) gewesen die es seit Jahren gibt und nie angegangen werden. Ich behaupte sogar mal, es hat nur Verbreitung weil es nichts anderes gibt. Unter Windows sieht man es ja, da gibt es die Alternative und wird genutzt.

OpenGL/Vulkan/Metal sind das was gepusht werden muss.

Dann Krempel die Ärmel hoch und fange an Bücher zu schreiben, Tools und Middleware zu Programmieren.

 

[Tranceport]

Der Knackpunkt von Vulkan (und DX12) ist aber doch, dass die Entwickler durch mehr Kontrolle und direkteren Zugriff auf die Hardware, mehr Leistung herausholen können, gegenüber den hardwareferneren APIs.
Ich kann mir deshalb schwer vorstellen, dass das dann einfach vollautomatisch durch eine Grafik-Engine oder gar einen Compiler erledigt werden kann. Vielleicht in so weit, dass es grundsätzlich funktioniert, aber um echte Performacevorteile rauszuholen, wird es doch sicher auf "Handarbeit" des Spieleentwicklers hinauslaufen.

Da hast du vermutlich absolut recht damit - mir geht es aber primär nicht um Leistung, sondern dass ich von Windows 10 wegkomme. Also selbst wenn die meisten Vulkantitel nur auf ein Leistungniveau mit DX11 kommen, ist mir das mehr als genug. Mehr gibt es auf Windows 7 auch nicht, und unter Linux mit OpenGL schon gleich dreimal nicht (von Wine mal garnicht zu reden)

 

[DocWindows]

mir geht es aber primär nicht um Leistung, sondern dass ich von Windows 10 wegkomme.

Versteh ich nicht. Ist DirectX das einzige was dich zu Win 10 greifen lässt? Das kann man doch sehr einfach ändern. Entweder Konsole kaufen oder einfach Spiele spielen die es auch für andere Systeme gibt. Wenn dich die Industrie mit 3-4 halbwegs interessanten Titeln pro Jahr an Windows 10 binden könnten, wäre das schon ziemlich traurig.

 

[Malmi]

Ich kann mir deshalb schwer vorstellen, dass das dann einfach vollautomatisch durch eine Grafik-Engine oder gar einen Compiler erledigt werden kann. Vielleicht in so weit, dass es grundsätzlich funktioniert, aber um echte Performacevorteile rauszuholen, wird es doch sicher auf "Handarbeit" des Spieleentwicklers hinauslaufen. Der Entwickler braucht dafür entsprechend mehr KnowHow und es kommen unweigerlich mehr potentielle Fehlerquellen hinzu, gegenüber der hardwareferneren, stärker automatisierten (und damit weniger optimierten) Methode der herkömmlichen APIs.

Im Wesentlichen geht bei der Nutzung solcher Engines doch gerade darum, dass man sich um solche Dinge(auch schon bei DirectX 11 etc.) weniger kümmern muss. Natürlich muss man auch da auf Bottlenecks achten etc.. Aber man steigt halt gerade nicht in die Tiefen der Grafikprogrammierung hinab. Dafür kauft man die Engine ein. Und mit den neuen APIs Vulkan und Direct3D 12 bekommen die Engineanbieter eine Möglichkeit den Spieleentwicklern noch bessere Performance/Grafik anzubieten.

 

[crvn075]

da es properitäter Mist ist und die Entwicklung lange genug gebremst hat. OpenGL/Vulkan/Metal sind das was gepusht werden muss. Das ist wichtig für cross platform Titel und würde die Portierung oder gar native Entwicklung für Linux und OS X/iOS massiv vorwärts bringen.

DX ist proprietärer Mist, aber Metal nicht?

 

[Ap2000]

Versteh ich nicht. Ist DirectX das einzige was dich zu Win 10 greifen lässt?

Sonstige Vorteile hat es nicht und selbst dieser ist nur künstlich erzeugt.

 

[Herdware]

Im Wesentlichen geht bei der Nutzung solcher Engines doch gerade darum, dass man sich um solche Dinge(auch schon bei DirectX 11 etc.) weniger kümmern muss.

Vorweg will ich schon mal zugeben, dass ich mich mit sowas wirklich nicht auskenne. Mein letztes Spiel habe ich in BASIC programmiert.

Ich frage mich halt, wie weit auch eine Gameengine hardwarenahe Programmierung automatisieren kann. Letztlich ist das dann ja auch nichts anderes, als was OpenGL und DirectX11 und älter auch schon immer getan bzw. versucht haben. Also z.B. die Verwaltung des VRAM zu übernehmen, ohne dass sich der Entwickler (des Spieles doer der Grafikengine) darum im Detail kümmern muss. Der Nachteil daran war z.B. verschenkte Performance oder größerer VRAM-Bedarf usw., gegenüber "handoptimiertem" Code.
Sicher weiß die Game-Engine schon mal etwas mehr über die speziellen Umstände eines darauf basierenden Spieles, als DirectX oder OpenGL. Aber das volle Potential könnte doch nur der Spieleentwickler selbst heraus holen, der Bescheid weiß, wann welche Texturen vorab geladen werden sollten, welche vielleicht wieder überschrieben werden können usw.

 

[noxon]

Wenn Compiler und die großen Engines Vulkan-tauglich sind (ohne großartige Anpassungen), ist schon viel gewonnen.

Aber selbst das ist nicht so einfach, wie man vielleicht denkt. Solche große Engines mal eben umzustellen ist recht aufwendig, besonders wenn sie schon eine sehr alte Codebasis haben, wie zum Beispiel die CryEngine.
Deren Ursprung hat die damals noch in DX9 gehabt und so sieht die Engine auch heute immer noch aus. Statusinformationen werden kreuz und quer durch die Engine mit Flags weitergereicht und weiterverarbeitet. Das macht es heut zu Tage allerdings unmöglich die Engine zu parallelisieren und multitaskingfähig zu machen, was aber nötig ist um die Vorteile der neuen APIs nutzen zu können.
Im Grunde genommen muss man also schon die komplette Engine von Grund auf neu strukturieren. Der simple objektorienteierte Ansatz von damals ist heute einfach nicht mehr zeitgemäß. Heut zu Tage arbeiten Engines eigentlich nur noch komponentenorientiert. Beispiel
Da steckt also eine irrsinns Arbeit drin die Engine auf DX12/Vulkan umzustellen. Die implementierung der API selbst ist hinterher eine kleinigkeit. Ob es sich dabei um DX12 oder Vulkan handelt ist letzendlich beinahe egal.

Und natürlich wird Vulkan Entwicklung mit einer professionellen Engine auch nicht unbedingt einfacher. Sinn und Zweck von Vulkan ist es ja, dass die Entwickler sich um alles selbst kümmern müssen, denn nur so kann man ja auch die nötige Performance erzielen.
Die Entwickler wollten es ja gerade so, dass sie auf alles selbst Zugreifen können. Das bedeutet dann aber auch, dass alles etwas schwieriger wird.
Wer das nicht will muss weiterhin OpenGL verwenden. Die API ist ja wegen Vulkan nicht gestorben.

 

[--jabber--]

Die Möglichkeiten und Einsatzgebiete sind jedoch vielversprechend, da die Ausgangslage deutlich moderner ist als OpenGL aber auch bereits OpenCL. Auf Android-Plattformen wird Vulkan bereits in Kürze die favorisierte Plattform – den Sprung hatte OpenCL nie geschafft.

Wieso hat Vulkan was mit OpenCL zu tun?
OpenCL ist computing Language. Ist quasi konkurenz zu Cuda.
Und Vulkan hat doch nicht viel mit computing zu tun.
Genauso wie DX12 auch nichts mit computing zu tun hat.

Das eine sind Grafik APIs ( DX12/11, OpenGl ,Vulkan) das andere Computing API's (Cuda, OpenCL)

Der absatz macht also wenig sinn. So wie ich das sehe.
Und Computing ist sowieso nicht so in der breiten masse genutzt.
Und wer will schon auf einem Android device number crunchen. CUDA ist ja auch nicht groß auf Android zu finden.
Denk ich zumindest.

 

[Bright0001]

Ich sehe hier keinerlei Grund Angst vor Vulkans Untergang zu haben, nur weils ne Low-Level API ist. Die Leute haben schon seit ner ganzen Weile mit C und C++ programmiert, und händische Speicherverwaltung tat der Popularität der Sprache keinen Abbruch.

Fehleranfälligkeit ist auch nur ein vorgeschobenes Argument, ein erfahrener Programmierer wird sich in eine beliebige Sprache gut einarbeiten und keine schwerwiegende inhaltliche oder strukturelle Fehler einbauen.

 

[GIGU]

Ich hoffe die Vulkan API zieht. Zwei dicke Fische sind sicher schon dabei: Valve und Google.
Valve ganz sicher wegen SteamOS, und Google zeigt auch interesse (Riesen Markt mit Android).

 

[spawa93]

Valve hat unverständlicherweise die Chance nicht genutzt, seine Steamos-Plattform zu pushen mit einem L4D3 oder einem Portal 3, irgendwas, das AA+ Niveau hat und das auf Vulkan setzt. Das hätte dem Zug Geschwindigkeit gegeben.

 

[Yuuri]

Valve hat unverständlicherweise die Chance nicht genutzt, seine Steamos-Plattform zu pushen mit einem L4D3 oder einem Portal 3, irgendwas, das AA+ Niveau hat und das auf Vulkan setzt.

Valve has confirmed that it will not be making games that are exclusive to SteamOS or Steam Machines.

Speaking to IGN, Valve’s Greg Comer said, “you won’t see an exclusive killer app for SteamOS from us. We’re not going to be doing that kind of thing.”

This will also apply to third-party titles, Valve’s Anna Sweet told us. “Whenever we talk to third-party partners, we encourage them to put their games in as many places as possible, including not on our platforms," she said. "Because we think that customers are everywhere, and they want to put their games wherever customers are. That would go against our whole philosophy, to launch something that’s exclusive to SteamOS or Steam machines.”

.

 

[noxon]

Wieso hat Vulkan was mit OpenCL zu tun?
OpenCL ist computing Language. Ist quasi konkurenz zu Cuda.
Und Vulkan hat doch nicht viel mit computing zu tun.
Genauso wie DX12 auch nichts mit computing zu tun hat.

DX12 und Vulkan haben natürlich auch etwas mit computing zu tun. Das sind sowohl Grafik als auch Compute APIs.
Graphics and Compute Belong Together

Das ist einer der Unterschiede zu OpenGL, welches in der Tat nur eine Grafik API ist. DX11 hingegen hat mit DirectCompute aber auch schon eine Compute-API enthalten. Das ist meiner Meinung nach auch immer einer der großen Vorteile von DirectX gewesen. Dort hatte man eigentlich immer gleich alle APIs zusammen unter einem Dach gehabt, während man sich bei OpenGL Spielen immer erst alle möglichen Bibliotheken zusammensuchen musste um alle Funktionalitäten zu implementieren, die man ansonsten auch mit DirectX bekommen hätte. Beispiel XInput und so weiter.