Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Next generation rendering API rants (Vulkan, DirectX12, Mantle)

Werbeanzeige

Spiele Programmierer

Alter Hase

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

41

28.03.2015, 17:05

OpenGL und Vulkan ist Objektorientiert.
Es gibt nur keine ABI für viele Plattformen, die es erlauben würde, OO direkt auszudrücken.
C++ besitzt keine standardisierte ABI und könnte auch von anderen Programmiersprachen sehr schwer zugegriffen werden. DirectX verwendet unter Windows COM. Das ist offensichtlich Windows only. Plattformübergreifende Software muss eigentlich ein C-Funktions-Interface besitzen.

Wer es gerne Cplusplusiger hätte, kann ich sich ja einfach selbst Klassen schreiben. Ich denke nicht, dass es derartig viele Funktionen geben wird, dass das eine große Aufgabe ist.

DeKugelschieber

Community-Fossil

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

42

28.03.2015, 17:13

Zitat von »Spiele Programmierer«

Wer es gerne Cplusplusiger hätte, kann ich sich ja einfach selbst Klassen schreiben. Ich denke nicht, dass es derartig viele Funktionen geben wird, dass das eine große Aufgabe ist.

Klar. Das ist auch das was ich aktuell mit GL mache. Kein großer Akt und man kann es "personalisieren".
Ich sehe es auch nicht zwangsläufig als Vorteil das Dx OO ist. Zumindest Code den ich bis jetzt so gelesen habe ist dadurch nicht unbedingt verständlicher oder kürzer.
Grüße, Kugel

GitHub Meine Firma Pirsch Analytics

David_pb

Community-Fossil

  • »David_pb« ist der Autor dieses Themas

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

43

29.03.2015, 12:12

Zitat von »Nimelrian«

Vulkan ist immer noch nicht "selbstständig" objektorientiert. Liegt aber daran, dass es halt auch auf anderen Geräten als Desktops eingesetzt wird.


Vulkan wird eine durchweg Objektorientierte API sein, genau wie Mantle.

Zitat von »Nimelrian«

Vulkan und DX12 haben beide stark bei Mantle abgeschaut. Vulkan hat egtl. genau dieselbe API. DX12 hat z.B. das Error Handling komplett übernommen


Das wurde ja schon häufig erwähnt. Vermutlich kann man das noch zig weitere Male erwähnen ohne das DeKugelschieber und Bambi das kapieren.

Zitat von »Spiele Programmierer«

OpenGL und Vulkan ist Objektorientiert.


Einige neuere APIs von OpenGL waren Objektorientiert. ObenGL ist es weitgehend aber nicht (vor allem ältere Teile). Vulkan hingegen wird komplett Objektorientiert sein, was ein Kapseln in eine Klassenstruktur deutlich schöner macht.

Zitat von »Spiele Programmierer«

Es gibt nur keine ABI


Was ist denn eine ABI?

Zitat von »DeKugelschieber«

Klar. Das ist auch das was ich aktuell mit GL mache.


Kann man, aber nicht besonders elegant und gut. Es gibt im Netz viele Diskussionen die das Thema behandeln. Der "globale State"-Ansatz den GL in weiten Teilen verwendet bildet sich nicht besonders gut auf ein objektorientiertes Design ab.
@D13_Dreinig

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

44

29.03.2015, 12:53

OpenGL ist imo durchwegs als objektorientierte API zu sehen. Das Problem ist nur, dass (vor allem in den älteren Teilen der API) jegliche Interaktion mit den "Objekten" nur indirekt und über die Modifikation von implizitem, globalen Zustand erfolgt, was einer Kapselung mit den herkömmlichen, objektorientierten Mitteln einen Riegel vorschiebt und die Benutzung der API, die zwar rein prinzipiell OO ist, in modernen OOP Sprachen zur absoluten Qual macht. Vulkan ist auch in dieser Hinsicht ein absoluter Lichtblick; bleibt zu hoffen, dass auch im Bereich der Kontexterzeugung endlich menschenwürdige Umstände geschaffen werden...
m4studios

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (29.03.2015, 12:59)

David_pb

Community-Fossil

  • »David_pb« ist der Autor dieses Themas

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

45

29.03.2015, 13:23

Zitat von »dot«

OpenGL ist imo durchwegs als objektorientierte API zu sehen. Das Problem ist nur, dass (vor allem in den älteren Teilen der API) jegliche Interaktion mit den "Objekten" nur indirekt und über die Modifikation von implizitem, globalen Zustand erfolgt, was einer Kapselung mit den herkömmlichen, objektorientierten Mitteln einen Riegel vorschiebt und die Benutzung der API, die zwar rein prinzipiell OO ist, in modernen OOP Sprachen zur absoluten Qual macht. Vulkan ist auch in dieser Hinsicht ein absoluter Lichtblick; bleibt zu hoffen, dass auch im Bereich der Kontexterzeugung endlich menschenwürdige Umstände geschaffen werden...


Naja, wenn dein Programm viele globale Objekte verwendet, die einen aktuellen Arbeitskontext bilden ist das auch nicht mehr Objektorientiert, oder? Zumindest mal entspricht das keinem guten objektorientierten Design. GL hat ja einige APIs die das gut lösen (z.B. program object apis), aber viele alte APIs sind schwer bis garnicht gut abzubilden, imo. Vulkan macht das deutlich besser. :)
@D13_Dreinig

Spiele Programmierer

Alter Hase

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

46

29.03.2015, 14:30

ABI

Um OpenGL objektorientiert zu verwenden, bietet sich EXT_direct_state_access und ARB_direct_state_access(OpenGL 4.5, noch wenig verfügbar) an.
Als Fallback kann man die alte API mit einem kleinen Overhead verwenden.

David_pb

Community-Fossil

  • »David_pb« ist der Autor dieses Themas

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

47

29.03.2015, 17:49

Zitat von »Spiele Programmierer«

ABI


Danke für den Link. Sieht interessant aus. :)
@D13_Dreinig

Julién

Alter Hase

Beiträge: 717

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

48

06.04.2015, 23:58

Noch WIP und hat auch nichts neues. Sollte nur unter Vorbehalt eingefügt werden: http://vulkan-tutorial.com/

Kann mir bitte jmnd. erklären warum die neuen API-Architekturen/Varianten schneller sind? Was ist überhaupt mit "Overhead" gemeint bzw. was bedeutet das eig.?
Wieso funktioniert multithread rendering überhaupt? Man hat soch trotzdem nur ein GPU Kern, der alles berechnet. Wieso ist das dann schneller?

MfG Julien
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

Tobiking

1x Rätselkönig

Beiträge: 1 231

  • Private Nachricht senden

49

07.04.2015, 02:17

Zitat von »Julién«

Kann mir bitte jmnd. erklären warum die neuen API-Architekturen/Varianten schneller sind? Was ist überhaupt mit "Overhead" gemeint bzw. was bedeutet das eig.?

Der als Quelle verlinkte Artikel aus deinem Link (http://blog.imgtec.com/powervr/trying-ou…on-powervr-gpus) gibt da einige Beispiele. Vieles läuft darauf hinaus das die Applikation die Verwaltung übernimmt, statt des Treibers. Bei Ressourcen bringt das z.B. den Vorteil, dass Daten nur im Grafikkarten- bzw. Arbeitsspeicher liegen und verwaltet werden müssen wenn sie auch noch gebraucht werden. Der Treiber weiß nicht was die Applikation vor hat und könnte daher nur die Daten durchgehend vorhalten.

Zitat von »Julién«


Wieso funktioniert multithread rendering überhaupt? Man hat soch trotzdem nur ein GPU Kern, der alles berechnet. Wieso ist das dann schneller?

Mit Multithread ist der Part auf der CPU gemeint. Auch wenn die CPU mit den neuen APIs entlastet wird, geht Zeit dafür drauf Buffer zu füllen, Shader zu compilieren, einen Drawablauf zusammen zu stellen etc. Der Treiber will ja trotzdem möglichst viele Optimierungen einbringen bevor alles an die Grafikkarte gesendet wird. Wenn man die Drawcalls unabhängig voneinander auf verschiedenen Kernen vorbereiten kann, ist da schon einiges an Zeit rauszuholen.

Julién

Alter Hase

Beiträge: 717

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

50

07.04.2015, 23:51

Also wird quasi der Draw()-Befehl an sich nicht beschleunigt (abgesehen von den ganzen Ressourcenmanagementsachen), sondern die Vorbereitung auf den Draw Call?
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

Werbeanzeige

Ähnliche Themen