Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Im Moment trifft sich mal wieder alles was im Grafikbereich Rang und Namen hat auf der SIGGRAPH, und Khronos hat jetzt auch wieder offizielle Infos rund um Vulkan, die moderne 3D und Compute API veröffentlicht.
Interessant dürfte v.a. die Tatsache sein dass Vulkan jetzt auch seitens Google auf Android unterstützt wird, und man so den gleichen Code (für seinen Renderer) auf dem Desktop und mobil laufen lassen kann.
Und eine neue OpenGL ES Version (3.2), sowie neue OpenGL Extensions (14 Stück), darunter auch eine mit der man Shader endlich multithreader compilieren und linken kann, wurden vorgestellt.
Kleiner Nachtrag (von mir) : Ich habe mal ein wenig zu Vulkan aus Sicht eines Hobbyentwicklers(Englisch) gebloggt. Nicht zu technisch, sondern eher generelle Sachen. Darunter auch einige Punkte die in vielen Pressemeldungen falsch war, z.B. das Vulkan OpenGL ersetzen wird oder 1:1 gleich zu Mantle ist.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Also irgendwie reißt mich das nicht vom Hocker, das war irgendwie schon klar.
ARM und Qualcomm hatten ja schon zum Annouce-Event ne Demo vorgestellt und da ist jetzt wirklich nicht viel zu machen es auf nen Android laufen zu lassen. Es gibt ein Vulkan Emulator der über OpenGL ES3.1 drüber liegt und Khronos hat zufälliger weise zur gleichen Zeit eine ES3.1 Support ARB gemacht und AMD/NV/Intel supporten die bei aktuellen Treibern. Von daher ist es nicht schwer mit dem gleichen Code auf Desktop und Mobile Vulkan bzw. OpenGL ES laufen zu lassen. Multithreaded Shader kompilieren ist auch schon mit SPIR announced worden.
Was allerdings wirklich interessant finde, wären die 14 neuen EXT/ARB Erweiterungen und was so in der ES3.2 steckt.
SIGGRAPH ist ja eigentlich auch der falsche Ort für solche Tech Anouncements, da findet man ja eher Post-Mortem Projekte/Studien oder Software. Ich freu mich auf jeden fall schon auf die ganzen Use-Case Papers
edit: Hab OpenGL ES2.1 auf 3.1 korrigiert !
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich bin gespannt, wieviel multithreaded shader kompilieren wirklich in der Ladezeit bringen wird. In meinen Demos hab ich in der Regel 2-3 Shader, da wird man nix merken aber bei richtigen Spielen, wo ich früher mit entwickelt hatte gab es locker 30-40 Shader und die Engine hat die alle am Anfang geladen. Bei sowas sollte man es spürbar merken, sonnst wäre die Arbeit für die Katz Wenn ich das richtig verstanden habe, dann wird SPIR erst als Extension angebunden, dann ARB und dann Core. Also kann man erwarten, dass man multithreaded Shader(SPIR) bekommt aber die nicht so gut optimiert sein werden, wie die Core Shader API erzeugten Programme(Hersteller implementierung).
Nach dem Zero Driver Overhead Slides hab ich meine Techdemo so umgebaut, dass die Shader Objekte wieder verwendet werden(das wusste ich bis dato nicht) und nur noch die Programm Objekte erzeugt und zerstört werden. Das hat beim Profilen tatsächlich die Zeit ordentlich reduziert aber wie gesagt hab ich nur 2-3 Shader und da fällt es dann nicht wirklich ins Gewicht. Das Linken der Programme kann recht aufwändig sein und je nach Shader und dessen Compiler Settings dauert es teilweise ziemlich lange.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Ich hab übrigens mal ein wenig über Vulkan, aus Sicht eines Hobby Entwicklers gepostet : http://www.saschawillems.de/?p=1886 (Nichts technisches, darf ja nicht zu viel verraten)
TAK2004 hat geschrieben:
Ich bin gespannt, wieviel multithreaded shader kompilieren wirklich in der Ladezeit bringen wird. In meinen Demos hab ich in der Regel 2-3 Shader, da wird man nix merken aber bei richtigen Spielen, wo ich früher mit entwickelt hatte gab es locker 30-40 Shader und die Engine hat die alle am Anfang geladen.
Wenn ich das richtig verstanden habe, dann wird SPIR erst als Extension angebunden, dann ARB und dann Core. Also kann man erwarten, dass man multithreaded Shader(SPIR) bekommt aber die nicht so gut optimiert sein werden, wie die Core Shader API erzeugten Programme(Hersteller implementierung).
Ja, SPIR wird ja dann mit dem glslang Referenzkompiler von Khronos erzeugt. Was aber nicht bedeutet dass der Treiber hier nicht optimiert, ist ja nur eine IR. Ich nehme an dass man hier früher oder später genau wie bei GLSL teilweise komplette Shader im Treiber umbaut damit sie besser performen.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.