Vulkan Grafik-API

[iuno]

OK, danke. Mit Veröffentlichung meinte ich ja auch die Spezifikation.
Bei Frostbite war es vielleicht auch naheliegend, weil die schon auf Mantle lief, aber die wird iirc gar nicht lizenziert oder? Kenne ich zumindest nur von EA Spielen (Battlefield, Battlefront). Aber Unity hört sich schonmal gut an.

[Unicous]

Lol. Schau dir einfach mal den ersten Post an.:freak:


Hatte ich gar nicht mehr auf dem Schirm. Trotzdem komisch, dass noch nicht offiziell Unterstützung zugesagt wurde.

[iuno]

Ja, ich hab gesehen, wer alles bei Khronos dabei ist, das muss ja nicht zwangsläufig heißen, dass auch Produkte folgen. Und den ganzen Thread wollte nicht nicht durchlesen, sorry :redface: auch weil es etwas abgeschweift ist

[Unicous]

Aber da die Leute zum Teil auch aktiv an dem Projekt mitgearbeitet haben, steigt die Wahrscheinlichkeit, dass sie Vulkan auch implementieren.:)

[Brillus]

OK, danke. Mit Veröffentlichung meinte ich ja auch die Spezifikation.
Bei Frostbite war es vielleicht auch naheliegend, weil die schon auf Mantle lief, aber die wird iirc gar nicht lizenziert oder? Kenne ich zumindest nur von EA Spielen (Battlefield, Battlefront). Aber Unity hört sich schonmal gut an.

Für Frostbite, gab es für 2-3 Monaten hier im Forum schon eine offzielle Slide wo sie geschrieben haben das sie ihr Mantle-Renderer in einen Vulkan-Renderer umbauen. (Die gleiche Folie wo explizit drauf stand das Vulkan ein angepasstest Mantle ist)

[Arcanoxer]

Nvidia To Show Off Vulkan On NVIDIA GPUs & An OpenGL Linux Graphics Debugger (https://www.gamingonlinux.com/articles/nvidia-to-show-off-vulkan-on-nvidia-gpus-an-opengl-linux-graphics-debugger.5778)

Between 9-10AM (LA Time) Nvidia will be hosting a "Vulkan on NVIDIA GPUs" talk

[SaschaW]

Und los gehts :
http://android-developers.blogspot.ca/2015/08/low-overhead-rendering-with-vulkan.html
https://www.khronos.org/news/press/khronos-expands-scope-of-3d-open-standard-ecosystem

:)

Btw. OpenGL und OpenGL ES werden auch weiter gepflegt. OpenGL bekommt 14 neue Extensions, darunter endlich eine um das Kompilieren und Linken von Shadern auf mehrere Threads zu verteilen : https://www.opengl.org/registry/specs/ARB/parallel_shader_compile.txt

[ScottManDeath]

Passender Treiber dazu https://developer.nvidia.com/opengl-driver :)

[Stebs]

Weitere Artikel:
http://anandtech.com/show/9509/vulkan-status-update-will-use-feature-sets-android-support-incoming
http://www.phoronix.com/scan.php?page=article&item=sig-gles32-glu&num=1

Auszüge:

To that end, today Khronos is announcing that Vulkan will support defined feature sets in order to help simplify application development and to more readily support mobile and desktop hardware under the same API.

Vulkan Conformance Tests Will Be Open Source

Google has officially confirmed Vulkan support is coming to Android!

While there was some hope and talk of Vulkan potentially being released for SIGGRAPH 2015, that is not the case... Unfortunately there isn't any more of a definitive timeline to share besides "later this year." Neil mentioned that Vulkan is continuing to advance well, there's tweaks and feedback as more developers toy with it, etc. With the Vulkan release later in the year, it may be released as a provisional specification, but it seems at least some implementations (a.k.a. drivers) will be ready.

Vulkan will have standardized extensions that by default will support Android, Mir, Windows (Vista and newer), Wayland, and X.

Neil mentioned it would be even possible to implement Vulkan support for Windows XP. At this time, Apple hasn't pursued Vulkan support for OS X.

[SaschaW]

Das interessante(ste) daran ist die Tatsache dass es rein API-technisch keinen Unterschied zwischen Mobil und Desktop geben wird (Ausgenommen Extensions).

Wer also eh nativ mit C++ entwickelt wird seinen Renderer sowohl für Desktop als auch Mobile nutzen können ohne jetzt auf die spezifischen Unterschiede eingehen zu müssen, wie z.B. bei OpenGL und OpenGL ES der Fall ist.

Es wird sehr sehr spannend (bzw. für manche Leute ist es dass schon ;) )

[Novum]

Passender Treiber dazu https://developer.nvidia.com/opengl-driver :)
Jain. Da fehlt was.

[Demirug]

Das interessante(ste) daran ist die Tatsache dass es rein API-technisch keinen Unterschied zwischen Mobil und Desktop geben wird (Ausgenommen Extensions).

Wer also eh nativ mit C++ entwickelt wird seinen Renderer sowohl für Desktop als auch Mobile nutzen können ohne jetzt auf die spezifischen Unterschiede eingehen zu müssen, wie z.B. bei OpenGL und OpenGL ES der Fall ist.

Es wird sehr sehr spannend (bzw. für manche Leute ist es dass schon ;) )

"Ich glaube nicht Tim."

Es gibt keine Aussage mit welcher Android Version Vulkan Support kommen soll. Und selbst wenn es mal vorhanden ist muss man noch eine ganze Zeit lang ältere Versionen unterstützen.

Apple hat sich überhaupt noch nicht geäußert. Also auch dort weiterhin erst mal OpenGL ES und Metal.

Bei Windows Phone sieht es im Moment eigentlich auch nicht danach aus als würde dort Vulkan unterstützt werden.

Ein Out of the Box Windows kann auch kein Vulkan. In wie weit es über Windows update kommen wird ist ebenfalls noch unklar. Würde aber auch nur eine Rolle spiele wenn es ein Zwangsupdate wäre und das sehe ich nicht.

Oder um es ganz einfach auszudrücken. Vulkan = Mehraufwand

[SaschaW]

PowerVR haben heute auch ne Vulkan Demo gezeigt, und gehen auch auf ein paar technische Details ein : http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es

Weniger CPU-Last = geringerer Akkuverbrauch, also wird sich Vulkan auf Android sicherlich recht schnell durchsetzen.

Klar, es ist keine API für Anfänger, aber auch ein Hobby-Entwickler kommt damit klar. Man muss halt ggü. OpenGL (auch AZDO und DSA) umdenken ;)

[SaschaW]

Ein Out of the Box Windows kann auch kein Vulkan. In wie weit es über Windows update kommen wird ist ebenfalls noch unklar. Würde aber auch nur eine Rolle spiele wenn es ein Zwangsupdate wäre und das sehe ich nicht.

Oder um es ganz einfach auszudrücken. Vulkan = Mehraufwand

Das läuft bei Vulkan ein wenig anders als bei OpenGL. Das geht rein über den Treiber ;)

Auf Apple wird es vorerst kein Vulkan geben, da wird man halt mit Metal bzw. GLES leben müssen.

[Novum]

Das läuft bei Vulkan ein wenig anders als bei OpenGL. Das geht rein über den Treiber ;)
Die GPU-Treiber sind auch Bestandteil der System-Updates bei Android. Ich wüsste nicht was das ändert.

Klar, es ist keine API für Anfänger, aber auch ein Hobby-Entwickler kommt damit klar. Man muss halt ggü. OpenGL (auch AZDO und DSA) umdenken ;)
Bezweifle ich.

[Demirug]

Das läuft bei Vulkan ein wenig anders als bei OpenGL. Das geht rein über den Treiber ;)

1. Die Treiber die aber derzeit mit Windows 10 ausgeliefert werden enthalten kein Vulkan. Und diese Zteiber sind leider die Baseline.

2. In vielen Fällen (z.B. mobile GPUs) wird über Windows update niemals ein neuere Treiber angeboten.

3. Es ist unklar ob Treiber welche es villeicht über Windows update gibt Vulkan enthalten werden.

4. GPU Treiber updates sind bisher optional => Kaum jemand installiert sie.

Am Ende des Tages wird sich erstmal nichts ändern außer das man jetzt eben noch ein weiteres Backed schreibt. In ein paar Jahren kann man dann vielleicht das OpenGL und OpenGL Es Backend entsorgen.

[SaschaW]

Am Ende des Tages wird sich erstmal nichts ändern außer das man jetzt eben noch ein weiteres Backed schreibt. In ein paar Jahren kann man dann vielleicht das OpenGL und OpenGL Es Backend entsorgen.

Behauptet ja auch keiner dass dann alle direkt auf Vulkan umsteigen. Dass sowas ein längerer Prozess ist ist klar.

[AffenJack]

2. In vielen Fällen (z.B. mobile GPUs) wird über Windows update niemals ein neuere Treiber angeboten.

Also auf meinem Laptop wurden neulich die Inteltreiber per Windows Update geupdated, weiß nicht wie das bei NV und AMD ist, aber zumindest bei Intel würde ich davon ausgehen.

4. GPU Treiber updates sind bisher optional => Kaum jemand installiert sie.


Bei Windows 10? Soweit ich das verstanden hab muss man Treiberupdates deaktivieren und standardmäßig sindse an. Ergo werden auch geupdated.

[Demirug]

Behauptet ja auch keiner dass dann alle direkt auf Vulkan umsteigen. Dass sowas ein längerer Prozess ist ist klar.

Sorry dann habe ich das

Wer also eh nativ mit C++ entwickelt wird seinen Renderer sowohl für Desktop als auch Mobile nutzen können ohne jetzt auf die spezifischen Unterschiede eingehen zu müssen, wie z.B. bei OpenGL und OpenGL ES der Fall ist.

wohl falsch interpretiert.

Das Problem ist btw nicht das OpenGL und OpenGL Es ein paar Unterschiede haben. Das Problem ist vielmehr das die Qualität der OpenGL Es Treiber eine Katastrophe ist.

Also auf meinem Laptop wurden neulich die Inteltreiber per Windows Update geupdated, weiß nicht wie das bei NV und AMD ist, aber zumindest bei Intel würde ich davon ausgehen.

Das hängt immer ein wenig vom Hersteller des Notebooks ab. Es ist aber inzwischen weitaus besser als früher.

Bei Windows 10? Soweit ich das verstanden hab muss man Treiberupdates deaktivieren und standardmäßig sindse an. Ergo werden auch geupdated.

Bei 10 habe ich es mir noch nicht angeschaut. Wenn die Treiber da jetzt endlich auch automatische updates bekommen um so besser.

[SaschaW]

Das Problem ist btw nicht das OpenGL und OpenGL Es ein paar Unterschiede haben. Das Problem ist vielmehr das die Qualität der OpenGL Es Treiber eine Katastrophe ist.

Ja, das stimmt. Deshalb hoffe ich ja das Khronos ordentliche Konformitätstests für Vulkan Implementationen vorgibt.

OpenGL ES ist wirklich ein Minenfeld.

Sorry dann habe ich das
...
wohl falsch interpretiert.


Ne, nicht direkt. Aber alles zu seiner Zeit ;)

[Novum]

Vulkan hat viel weniger Komplexität in der Runtime, ich denke die Treiberqualität wird deutlich besser sein als bei OpenGL.

[Kartenlehrling]

http://www.golem.de/news/grafikschnittstelle-vulkan-rendert-unter-android-mehr-als-doppelt-so-schnell-1508-115679.html
Vulkan rendert unter Android mehr als doppelt so schnell

Google hat angekündigt, dass das Android-Betriebssystem für mobile Geräte die Vulkan-Grafikschnittstelle unterstütze.
Imagination Technologies zeigt die passende Demo auf einem Nexus Player.
Die als Gnome Horde bezeichnete Vorführung vergleicht das Open-GL-ES-3.0- mit dem Vulkan-API und zeigt,
dass letzteres deutlich schneller rendert und dabei die Hardware sowie den Akku weniger belastet.
Künftige Smartphonespiele könnten also länger laufen, wenn Entwickler die neue Grafikschnittstelle nutzten.

[SaschaW]

http://www.golem.de/news/grafikschnittstelle-vulkan-rendert-unter-android-mehr-als-doppelt-so-schnell-1508-115679.html
Vulkan rendert unter Android mehr als doppelt so schnell

Ist ja auch logisch. Man kann die CPU-Kerne viel effizientert nutzen (dank der Commandbuffer) und ganz viel Treiberoverhead fällt weg, der in OpenGL noch nötig war ;)

Irgendwo gabs mal nen Blogbeitrag von nem NVIDIA-Treiberdev, der drüber philosophiert hat wie viele tausend Zeilen Code man für den OpenGL Treiber hat nur damit ein glClear in allen Situationen sauber durchläuft (!). Das ist unter Vulkan alles viel schöner, v.a. für die IHVs.

[Novum]

Ich wüsste nicht was für den Benutzer der API schöner sei soll als ein einfaches "glClear", das alle Fälle abdeckt.

[mboeller]

IMG Demo:

http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es

laut Rys (im Beyond3D Forum gelesen) soll die Seite bis Ende der Woche noch einmal ein Update bekommen weil nach dem Khronos Group BoF meeting am Mittwoch mehr erklärt werden darf.

[SaschaW]

Ich wüsste nicht was für den Benutzer der API schöner sei soll als ein einfaches "glClear", das alle Fälle abdeckt.

Bei einer API gehts nicht nur um die ISVs, sondern auch die IHVs. Und kleinere, wohl definierte Runtime bedeutet leichtere Treiberentwicklung die zu weniger Fehlermn führt.

Hab mir mit OpenGL und OpenGL ES schon Tage und Nächte mit Treiberbugs um die Ohren geschlagen ;)

[Novum]

Bei einer API gehts nicht nur um die ISVs, sondern auch die IHVs.
Das war nicht deine Aussage, du hast nicht explizit von den IHVs gesprochen. "v.a. für die IHVs". Die Aussage wäre richtig "nur für die IHVs".

Für den Benutzer der API ist es schlicht mehr Code, mehr Komplexität und mehr Wartungsaufwand.

Hab mir mit OpenGL und OpenGL ES schon Tage und Nächte mit Treiberbugs um die Ohren geschlagen ;)
DirectX 11 hat das Problem nicht und ist trotzdem nicht low level. Und das ist der Maßstab an dem sich eine API messen muss.

Und glaube mir, die ganze Synchronisierung, Resourcen-Management und die Parallelität die einem Vulkan aufbürdet wird wesentlich mehr Zeit fressen als Treiberbugs in OpenGL. Das gleiche gilt natürlich auch für Direct3D 12.

Ich halte es auch gewagt das den Android-Programmierern zumuten zu wollen. Man kann durchaus Code schreiben, der dann nur auf einer GPU läuft weil zufällig bestimmte Formate keine Memory Barrier brauchen um anders verwendet zu werden etc. Das wird ein Bug-Massaker in dem Ökosystem.

[Demirug]

DirectX 11 hat das Problem nicht und ist trotzdem nicht low level. Und das ist der Maßstab an dem sich eine API messen muss.

Die Bugseuche bei DirectX ist geringer weil es einen sehr extensive Testprozess gibt. Bei OpenGL (ES) gibt es da so in der Form einfach nicht.

Der zweite Punkt ist das OpenGl sehr viel Atlasten hat welche die Komplexität sehr hoch treiben.

Und glaube mir, die ganze Synchronisierung, Resourcen-Management und die Parallelität die einem Vulkan aufbürdet wird wesentlich mehr Zeit fressen als Treiberbugs in OpenGL. Das gleiche gilt natürlich auch für Direct3D 12.

Das wird im wesentlichen von Tools abhängen welche auf potenzielle Probleme prüfen.

Ich halte es auch gewagt das den Android-Programmierern zumuten zu wollen. Man kann durchaus Code schreiben, der dann nur auf einer GPU läuft weil zufällig bestimmte Formate keine Memory Barrier brauchen um anders verwendet zu werden etc. Das wird ein Bug-Massaker in dem Ökosystem.

Das ist schon mit OpenGL ES ein Bugmassaker wenn man an die Grenzen des machbaren geht.

Es gibt nicht den "Android-Programmierer". Zum Beispiel schreibe ich Android code aber keine einzige Zeile Java. Vulkan ist eindeutig für die Leute die sowas auch auf anderen Plattformen machen. Die anderen können bei OpenGL ES bleiben.

[SaschaW]

Und glaube mir, die ganze Synchronisierung, Resourcen-Management und die Parallelität die einem Vulkan aufbürdet wird wesentlich mehr Zeit fressen als Treiberbugs in OpenGL. Das gleiche gilt natürlich auch für Direct3D 12.

Definitiv "Nein". Mehr sag ich dazu dann aber auch nicht mehr *hust*

D
Ich halte es auch gewagt das den Android-Programmierern zumuten zu wollen. Man kann durchaus Code schreiben, der dann nur auf einer GPU läuft weil zufällig bestimmte Formate keine Memory Barrier brauchen um anders verwendet zu werden etc. Das wird ein Bug-Massaker in dem Ökosystem.
Ganz im Gegenteil. Sehe ich wie Demirug. Zumal es strengere Konformitätstests geben wird als bei OpenGL ES, was die Gesamtqualität der Implementation entscheiden verbessern sollte. So eine Katastrophe wie mit OpenGL ES wird es nicht nochmal geben, bzw. könnte man sich nicht nochmal leisten.
Für den Entwickler gibts dann mit den diversen Validierungslayern auch umfangreiche Hilfsmittel um auf Fehler und Probleme zu reagieren :)

[Novum]

Ganz im Gegenteil. Sehe ich wie Demirug. Zumal es strengere Konformitätstests geben wird als bei OpenGL ES, was die Gesamtqualität der Implementation entscheiden verbessern sollte. So eine Katastrophe wie mit OpenGL ES wird es nicht nochmal geben, bzw. könnte man sich nicht nochmal leisten.
Ich rede nicht von der Implementierung auf Treiber-Seite, sondern was die Applikation macht.

Für den Entwickler gibts dann mit den diversen Validierungslayern auch umfangreiche Hilfsmittel um auf Fehler und Probleme zu reagieren :)
Die Validierungslayer sind schön und gut, aber solange nicht forciert wird, dass die Applikationen auch mit diesem fehlerfrei laufen wird das viele Entwickler nicht daran hindern zu pfuschen. Und Google lässt jeden Dreck in den App-Store.

Mach mal den DirectX-Debug-Layer an und lass Spiele laufen. Da vergeht dir das Lachen.

[Nightspider]

Ließe sich damit auch die normale Android-Oberfläche beschleunigen sowie alle Apps?

[Air Force One]

Theoretisch ja.
Aber praktisch ist wieder eine andere Sache

[Novum]

Ergibt keinen großes Sinn, die UI hat extrem wenige Drawcalls verglichen mit einem Spiel.

[del_4901]

Ergibt keinen großes Sinn, die UI hat extrem wenige Drawcalls verglichen mit einem Spiel.
Wenn man Analytic Line AA etc macht dann kommt schon was zusammen.

[Novum]

Macht das Android? Keine Ahnung.

[d2kx]

LyyKj2LJ0E0

[del_4901]

Macht das Android? Keine Ahnung.
UI ohne analytic line AA, glyph AA und den ganzen drumrum wuerde sich heute doch keiner mehr antun.

[SaschaW]

Livestream BOF : http://www.ustream.tv/channel/khronos-siggraph/theater

[Novum]

UI ohne analytic line AA, glyph AA und den ganzen drumrum wuerde sich heute doch keiner mehr antun.
IIRC rendert das aber die CPU in ne Textur. Aber keine Ahnung ¯\_(ツ)_/¯

[SaschaW]

UI ohne analytic line AA, glyph AA und den ganzen drumrum wuerde sich heute doch keiner mehr antun.

Sollte über Shader gehen (SDF evtl.). Hier gibts einen interessanten Artikel zum Font Renderer in Android : https://medium.com/@romainguy/androids-font-renderer-c368bbde87d9 (k.a. ob der noch aktuell ist).

Rein technisch kommen da schon ein paar Drawcalls zusammen, ein bisschen Performance (und damit Akkulaufzeit) kann man mit Vulkan sicherlich rausholen.

Aber dann halt nur auf GPUs die das auch unterstützen.

[Demirug]

Sollte über Shader gehen (SDF evtl.). Hier gibts einen interessanten Artikel zum Font Renderer in Android : https://medium.com/@romainguy/androids-font-renderer-c368bbde87d9 (k.a. ob der noch aktuell ist).

Rein technisch kommen da schon ein paar Drawcalls zusammen, ein bisschen Performance (und damit Akkulaufzeit) kann man mit Vulkan sicherlich rausholen.

Aber dann halt nur auf GPUs die das auch unterstützen.

Das ist mehr oder weniger das Standardverfahren das Spiele schon seit Ewigkeiten nutzen. Das eigentlich kritische ist wie man schöne Glyphen bekommt. Das macht wohl jeder nach wie vor auf der CPU. Android benutzt dafür wie die meisten anderen wohl auch Freetype. Hatte gerade erst wieder meinen Spaß damit. Emojis sind echt ein Krampf.

[SaschaW]

Ich hab mal ein wenig was zu Vulkan gebloggt (http://www.saschawillems.de/?p=1886) (Englisch).

Der Artikel geht in Richtung Hobby Entwickler und geht auch auf ein paar Punkte ein die in einigen Pressemeldungen falsch rüberkamen.

Es gibt keine technischen Details, sondern eher für den der generell daran interessiert ist und bisher OpenGL nutzte, sich aber nicht sicher ist ob Vulkan was für ihn ist.

Eher nix für die die tief in der Materie ist, aber evtl. für den ein oder anderen doch ganz interessant ;)

[SaschaW]

Vulkan SIGGRAPH 2015 BOF ab 1:10 : https://www.youtube.com/watch?v=faYDPjI2zhU

[S940]

Vulkan SIGGRAPH 2015 BOF ab 1:10 : https://www.youtube.com/watch?v=faYDPjI2zhU

PDFs dazu:
https://www.khronos.org/assets/uploads/developers/library/2015-siggraph/3D-BOF-SIGGRAPH_Aug15.pdf

[-/\-CruNcher-/\-]

Also irgend jemand in der Industrie sollte sich mal gedanken um Projektor VGA/HDMI interoperabilität machen es kann doch nicht sein das die scheisse immer wieder bei sowas versagt das ist doch ober peinlich als geek da zu stehen und die Projektor Verbindung spinnt ;)

Und man brauch minimum 4 mann um eine Verbindung hinzubekommen, da bin ich immer wieder überrascht was da schief läuft das sieht man ja auch öfter ;)

Da muss man mal ein Compilation Video von machen wie viel zeit für sowas immer drauf geht ;)

[Novum]

WTF? Was hat das mit Vulkan zu tun?

[Screemer]

Genau so viel wie seine nervenden Smileys. Gar nix.

[-/\-CruNcher-/\-]

Intel und Nvidia sind am besten aufgetreten sah bei Intel sogar aus wie ein Nuc oder ne WIDI Box dazwischen einfach dran boom erkant boom bild und das in High Speed so muss das sein, Intel waren anscheinend auch die einzigen die auf W10 Vulkan gedemoed haben :D

Intel wird auch mit am meisten von Vulkan und DX12 profetieren mit ihren x86 Atoms ;)

Sieht gut aus vor allem das aus Mantle das Cross Platform bestehen bleibt da kann man sich einen DX12 Path so gut wie total sparen brauch den nicht noch extra pflegen das ist nicht schlecht und die Performance scheint ja Native durch die Treiber ohne wirklichen Einbruch von statten zu gehen da werden die Erfahrungen der ISVs interessant werden vor allem auf Intel und AMDs x86 Windows Platformen mit dem Vulkan Treiber dazwischen man scheint sich ja auch ordentlich gedanken über die verschiedenen composition manager gemacht zu haben zwischen die man springt mit WSI :)

[Achill]

Ich mach mal mit ... der Nvidia Guy am Ende war schon nicht schlecht. Am besten hat mir seine Beteuerung am Anfang gefallen, wie wichtig Nvidia das offene Vulkan ist und nicht durch einen Hersteller dominiert / definiert wird - er sagt das glaube 3 Mal. AMD war auch evil mit dem proprietären Mantle. Gut das er den Dank von dem Kronos Guy bzgl. Mantle nicht gehört hat, ich hätte ja die Präsentation abgebrochen.

Ich freue mich dann auch sehr das NV endlich begriffen hat, dass offen wichtig ist. Bin daher gespannt wann GameWorks und co dann offen werden und eine Beteiligung anderer Hersteller passiert ... :devil:

Außerdem kann ich endlich wieder ruhig schlafen, da mir die Angst genommen wurde (und anderen bestimmt auch), dass es keine Vulkan-Treiber geben wird. War ja in anderen Foren hier aufgekommen aka Henne-Ei-Problem.

[SaschaW]

Außerdem kann ich endlich wieder ruhig schlafen, da mir die Angst genommen wurde (und anderen bestimmt auch), dass es keine Vulkan-Treiber geben wird. War ja in anderen Foren hier aufgekommen aka Henne-Ei-Problem.

Inzwischen haben alle IHVs Vulkan Implementationen. Sowohl auf Desktop, als auch mobil. Haben auch inzwischen alle was Lauffähiges gezeigt.

Aufgrund der ganzen ISVs die da mit dabei sind, v.a. was Engines angeht (Unity, Unreal und Co.) und der damit breiten Unterstützung kann es sich auch kein IHV erlauben Vulkan nicht zu unterstützen.

Ich freue mich dann auch sehr das NV endlich begriffen hat, dass offen wichtig ist. Bin daher gespannt wann GameWorks und co dann offen werden und eine Beteiligung anderer Hersteller passiert ...
Das ist doch nix neues gegenüber dem Status Quo. NVIDIA hat schon lange die besten OpenGL Treiber und ist immer ganz vorne dabei wenn es um neue Extensions und Versionen geht. Also ggü. bisher ist die Unterstützung von Vulkan ja nix neues.

[-/\-CruNcher-/\-]

jo sieh ünterstützen ja vom get go alle 13 neuen extensions zumindest auf Maxwell wie man raus hören konnte ;)

Intels eigene Demo zeigt ja auch sehr ordentliche Gewinne die man übrigens in zahlen von ihrem Treiber auf der GDC sehen konnte es war ein improvement von ~33 ms zu ~23 ms bei weniger power consumption in ihrer Stardust Demo :)

Ob sich seit dem weiterhin etwas getan hat kann man leider bei der Videoqualität nicht sehen :(

[Timbaloo]

Ob sich seit dem weiterhin etwas getan hat kann man leider bei der Videoqualität nicht sehen :(
Du meinst bei der video quality.

[SaschaW]

jo sieh ünterstützen ja vom get go alle 13 neuen extensions zumindest auf Maxwell wie man raus hören konnte ;)

Das ist auch wirklich so. Einen passenden Treiberreport (http://opengl.delphigl.de/gl_generatereport.php?reportID=927) dazu hat einer meiner glcapsViewer-Nutzer auch schon hochgeladen.

Intels eigene Demo zeigt ja auch sehr ordentliche Gewinne die man übrigens in zahlen von ihrem Treiber auf der GDC sehen konnte es war ein improvement von ~33 ms zu ~23 ms bei weniger power consumption in ihrer Stardust Demo :)
Ist auch logisch. Die Vulkan ICDs sind viel kleiner und müssen viel weniger Randbedingungen beachten, d.h. sich um weit weniger Altlasten als die OpenGL ICDS kümmern. Zusammen mit dem Wegfall der fiesen Statemachine aus der OpenGL-Steinzeit zugunsten von PSOs, die vom Treiber optimiert und gehasht werden können, und der besseren Drawcall-Performance profitiert eigentlich jeder in Sachen Performance. Wobei 33ms zu 23ms erst der Anfang ist ;)

[-/\-CruNcher-/\-]

Ja dieses improvment werd ich mal versuchen so zu verdeutlichen das ist ungefähr das gleiche als wenn man von 1200 Mhz bei GM204 unter DX11 auf 1500 Mhz übertaktet nur mit dem unterschied das man für das eine extra zahlt als Konsument und zwar doppelt manche sogar 3 fach so gern für diesen Treiber overhead ;)

[Troyan]

nVidia und Vulkan:
https://www.youtube.com/watch?v=8xBuAdnIrJQ

Ich mach mal mit ... der Nvidia Guy am Ende war schon nicht schlecht. Am besten hat mir seine Beteuerung am Anfang gefallen, wie wichtig Nvidia das offene Vulkan ist und nicht durch einen Hersteller dominiert / definiert wird - er sagt das glaube 3 Mal. AMD war auch evil mit dem proprietären Mantle. Gut das er den Dank von dem Kronos Guy bzgl. Mantle nicht gehört hat, ich hätte ja die Präsentation abgebrochen.

Ich freue mich dann auch sehr das NV endlich begriffen hat, dass offen wichtig ist. Bin daher gespannt wann GameWorks und co dann offen werden und eine Beteiligung anderer Hersteller passiert ... :devil:

Außerdem kann ich endlich wieder ruhig schlafen, da mir die Angst genommen wurde (und anderen bestimmt auch), dass es keine Vulkan-Treiber geben wird. War ja in anderen Foren hier aufgekommen aka Henne-Ei-Problem.

Soll das ernst gemeint sein? :freak:
Als ob nVidia weder Direct3D noch OpenGL unterstützen würde. ;D

[Achill]

...
Soll das ernst gemeint sein? :freak:
...


Natürlich nicht, ich bezog mich nur auf die Aussagen des NV Guys - ich fand sein Mantra zu offenen Standards nur so gut. Direct3D noch OpenGL habe ich damit natürlich nicht gemeint.

[Troyan]

Du behauptest doch, nVidia hätte keine offenen Standards unterstützt...

Vielleicht solltest du nochmal die nVidia-Präsentation ansehen: Eine "offene" API ist natürlich im Sinne von nVidia, da sie hier selbstständig Erweiterungen veröffentlichen können.

Das ist weder mit Direct3D noch Mantle möglich.

[Menace]

Du behauptest doch, nVidia hätte keine offenen Standards unterstützt...


Da ich keine Lust habe, 54 Minuten Video zu schauen: Hat nvidia zu OpenGl im allgemeinen beigetragen oder nutzen sie es nur und passen sie es an ihre Grafikkarten an?

[StefanV]

Du behauptest doch, nVidia hätte keine offenen Standards unterstützt...
Stimmt ja auch.

Siehe CUDA, OpenCL, VESA Adaptive Sync...
Da gibts sicher noch mehr...

Dass man das unterstützt, was man muss, sollte klar sein...

[SaschaW]

Da ich keine Lust habe, 54 Minuten Video zu schauen: Hat nvidia zu OpenGl im allgemeinen beigetragen oder nutzen sie es nur und passen sie es an ihre Grafikkarten an?

NVIDIA trägt sehr viel zu OpenGL bei. Einfach mal in die Extensionspecs schauen, da steht oben ja immer drin wer daran mitgearbeitet hat. Mal ganz von den vielen NV_* Extensions abgesehen von denen auch viel als ARB in GL selbst eingeflossen ist.

[Menace]

Es freut mich (als Kunden) wenn nvidia für alle etwas zu OpenGl beiträgt. Da ich mich bei OpenGl nicht auskenne: NV_Extensions sind also auch mit AMD/intel-Grafikkarten nutzbar?

[Novum]

Neue Features werden normalerweise zuerst als IHV spezifische Extensions entwickelt, dann später in den Standard übernommen.

Manchmal implementiert aber auch ein anderer IHV die Extension der Konkurrenz, das ist erlaubt.

[Menace]

Neue Features werden normalerweise zuerst als IHV spezifische Extensions entwickelt, dann später in den Standard übernommen.

Manchmal implementiert aber auch ein anderer IHV die Extension der Konkurrenz, das ist erlaubt.

Ihr sagt es aber auch ungern direkt, oder verstehe ich das nur so schlecht? :wink:

Extensions sind also Herstellerbezogen (nvidia -> nvidia)?
Die Extensions liegen aber offen vor, so dass jeder Hersteller dieser sie lesen und für seine Grafikkarten umschreiben kann? Und das gilt prinzipiell für alle Extensions?

Bitte entschuldigt, dass ich da so nachfrage. Mir ist das alles noch nicht ganz klar.

[OBrian]

Extension heißt, daß ein Chiphersteller in Hardware was neues erfindet, was in der API nicht angesprochen werden kann. Dafür programmiert er eine neue Funktion, die er dann der API hinzufügt. Klar kann die auch ein anderer Hersteller nutzen, nur nützt ihm die ja solange nichts, bis er in seiner Hardware auch sowas eingebaut hat. Und ist das dann etwas anders, muß er evtl. seine eigene Extension schreiben, die dem Anwendungsprogrammierer das gleiche bietet, aber etwas anders umsetzt.


Übrigens wäre ich mit dem Begriff "unterstützen" vorsichtig, bzw. erfordert der eine Erklärung, was damit gemeint ist. Denn der gehört auch zu den Worten, die inzwischen von den Sprachpanschern der Marketingabteilungen so entwertet sind, daß alles damit gemeint sein kann. Für mich bedeutet Unterstützung eine Hilfe, eine Erleichterung oder Beschleunigung der Entwicklung. Aber man findet auch oft "Dieses Gerät unterstützt X", somit nur gemeint ist, daß man X dazukaufen muß, damit es funktioniert, oder bestenfalls, daß X nicht aktiv bekämpft und blockiert wird. Z.B. eine PCIe-Karte "unterstützt" den Standard ja nicht, der Standard hat nix davon, richtig wäre "die Karte erfüllt den Standard".

[Guest83]

Porting Source 2 to Vulkan Siggraph Präsentation Slides:

http://nextgenapis.realtimerendering.com/presentations/6_Ginsburg_Source2.pdf


Irgendwas interessantes darin enthalten? Ist für mich leider eine Spur zu technisch.

[samm]

Ein bisschen wurde darüber im DX 12 Thread gesprochen startend mit diesem Post (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10745060#post10745060). Sie versuchen Threading und Command Submissions nicht übermässig zu benutzen, und auch die von der API gegebenen Möglichkeiten zu Wiederverwendung von gewissen Objekten wird nicht gänzlich ausgenutzt, um praktische Probleme zu vermeiden.

Im Gegensatz zum Unity-Port auf DX 12 sprechen sie aber nicht davon, dass derzeit letztlich keine erhöhte Performance resultiert, vermutlich weil Source doch etwas zukunftsorientierter umgebaut wurde als Unity bisher, drum würd ich sagen kommt das schon gut.

[tdon]

https://www.youtube.com/watch?v=llOHf4eeSzc


Vulkan in der Stardust Demo auf Intel läuft doppelt so schnell.

[aufkrawall]

Sollten die Vulkan-Specs nicht im Herbst fertig sein? Er sprach von bis Ende des Jahres.

[Gipsel]

https://www.youtube.com/watch?v=llOHf4eeSzc


Vulkan in der Stardust Demo auf Intel läuft doppelt so schnell.
Was zeigen die denn da? Die blauhaarige Schwester von Ruby?

http://abload.de/img/intel_vulkan_figurhmr7l.jpg http://abload.de/img/rubynnqn2.jpg

[aufkrawall]

Soll wohl auf die griechische Mythologie anspielen.
Ruby hat ja nicht so eine schillernde Herkunft...

[Gipsel]

Soll wohl auf die griechische Mythologie anspielen.
Ruby hat ja nicht so eine schillernde Herkunft...Ah, deswegen wohl die Ornamente. Aber das ist dann mies recherchiert. Vulcanus war ein Typ und nicht die griechische Version, sondern die römische (Hephaistos wäre griechische Mythologie, aber immer noch ein Typ). Aber wen interessieren schon solche Kleinigkeiten :rolleyes:.
Edit: Die Mäander-Ornamente haben die Römer auch noch benutzt. /OT

[aufkrawall]

Ein Typ dürfte für den Großteil des interessierten Publikums wohl nicht so interessant sein.
Da könnte auch die Mentalität in Asien eine Rolle spielen. Aber irgendwo ist das doch hier OT. :D

[SaschaW]

Sollten die Vulkan-Specs nicht im Herbst fertig sein? Er sprach von bis Ende des Jahres.

Specs ja, SDK noch nicht. ETA ist immer noch Ende des Jahres.

[Jupiter]

Aus ask a dev (Star Citizen-Forum)

Frage:
With Vulkan (based on Mantel API by AMD) it is now possible to stack VRAM in Crossfire/SLI so that 2 cards with 4GB VRAM becomes 8GB of VRAM. This is achieved through split-frame rendering with each GPU ad its respective framebuffer handling 1/2 of the screen

Antwort des Senior Graphic Engeneers (Foundry 42; Ben Parry):
Split-frame rendering is one of those ideas that sounds marvellous, and maybe gets you something, but probably won't get you as much as you'd hope.
The good: There's obviously some memory that you really don't need to have on both cards. The main colour buffer could be split in half, the buffers we use for deferred shading, and the depth buffer are all good candidates. With an intelligent culling system you'd be sending less draws and vertices to each too. While those are some chunky textures, though, they're not where the majority of the memory's spent.

The bad: Suppose you're flying along with a Bengal carrier on your left side. To save memory, it's only loaded into your left-hand GPU. Suddenly you swing the nose around and look at it head on - we now need a copy of those resources on both cards. So now we need to select a ton of stuff on that other GPU to evict, possibly defrag it, and copy the Bengal over to it, without causing frame drops. It'd be a lot more stable to maintain the same meshes/textures/etc on both GPUs, but that's the majority of memory use, so your stacking goes out the window.

The ugly: Shadows. Sad to say no matter which GPU draws a shadow buffer, both sides are going to want access to it. If you're dead set on having both GPUs work on a frame, that means some time spent copying shadow buffers from one card to the other. On top of that, anything that accesses nearby pixels (motion blur, bloom, depth of field, for example) need access across the dividing line. This means you have to know the largest crossover and either sync that strip of screen, or waste a little work by rendering the overlap on both GPUs.

I think there's definitely room for two GPUs to work on one frame, but the main benefit you'd get over AFR is reduced latency rather than a bigger memory pool. At the risk of not having perfect load-balancing, you could push all shadow rendering to one GPU and do it in parallel with your main scene draw, for instance, possibly move some expensive postprocessing out there, and obviously there are Vulkanists who've pointed out the natural fit of 1-GPU-per-eye VR.
If you're not doing VR, though, and you're not one of these superhumans who can see the added input lag, conventional alternate frame multi-GPU stuff is probably going to give you the most stable use of resources.

Quelle: https://forums.robertsspaceindustries.com/discussion/95610/persistent-universe-programming/p6

[Novum]

Breaking news: SFR skaliert nicht.

[Chris Lux]

Breaking news: SFR skaliert nicht.
Es skaliert, wenn man weiß was man macht und man eben viel Arbeit investiert. Der letzte Punkt ist halt kritisch, weil wieso viel Arbeit investieren wenn es nur ein Bruchteil der Zielgruppe auch nutzt.

Ich bin mir nicht sicher ob die multi-GPU Funktionalität überhaupt noch für Vulkan 1.0 angedacht sind.

[samm]

Ich bin mir nicht sicher ob die multi-GPU Funktionalität überhaupt noch für Vulkan 1.0 angedacht sind.Denke schon, weil es im Konkurrenten DX12 samt Demo-Hype zu asynchronem Multi-GPU schon gezeigt wurde und für Mantle auch schon eingebaut wurde.

[Nightspider]

Ich glaube hier passt es am besten rein:

Wurden schon die Async Compute Units bei BF4 mit Mantle genutzt?

Da die GPU Leistung nicht anstieg gehe ich mal davon aus das dies nicht der Fall war.
Dann frage ich mich aber auch warum die das nicht gemacht haben.

[Unicous]

iirc, haben sie nur damit rumgespielt es aber dann doch nicht implementiert, weil es noch nicht verlässlich funktionierte.


Hier spricht Andersson drüber:

http://www.gdcvault.com/play/1020830/Rendering-Battlefield-4-with-Mantle


http://de.slideshare.net/DICEStudio/rendering-battlefield-4-with-mantle

Ab 41 bzw. 43.


Up to 80% faster, but not fully reliable

-Not in BF4 yet

[Locuza]

AMD gab nur für Thief den Einsatz von Async Compute unter Mantle an.
Für BF4 nur unter der PS4:
http://images.anandtech.com/doci/9124/Async_Games_575px.png

Es gab noch eine Präsentation von DICE bezüglich Rendering BF4 with Mantle:
http://www.frostbite.com/2014/03/rendering-battlefield-4-with-mantle/

Da wird auch auf Async Compute eingegangen.
Auf Seite 43 heißt es, dass man Stellenweise bis zu 80% mehr Speed rausholen konnte, es aber nicht völlig zuverlässig sei.
Vielleicht war es ihnen zu unvorhersehbar oder es war einfach noch zu früh den zusätzlichen Aufwand zu stemmen, dass noch unter Mantle umzusetzen und sie haben es einfach gelassen.

Interessant ist sowieso jetzt nur die Zukunft mit DX12 und Vulkan.

Edit: Damn you Unininja.

[Kartenlehrling]

Wurden schon die Async Compute Units bei BF4 mit Mantle genutzt?

Laut einer AMD Folie wurde async shaders auf der PS4 für BF4 genutzt.


muhhh zulangsam ...

[Unicous]

Edit: Damn you Unininja.


MUAHAHAHAHA. I win. Again. MUAHAHAHAHA.

(Das mit BF4@PS4 hatte ich schon wieder ausgeblendet, obwohl die Folie ja nur ein paar Monate alt ist)

[Nightspider]

Seltsam. Kann mir nicht vorstellen, dass das so viel Mehrarbeit gewesen wäre beim PC wenn man es schon auf der PS4 nutzt.

[dargo]

Bis zu +80% ist aber ne echte Kampfansage. :eek:

[Nightspider]

Wahrscheinlich nur in bestimmten Situationen bei bestimmten Berechnungen. Global +80% mehr GPU Leistung kann nicht sein.

[dargo]

Was ist bei "bis zu" so unverstädlich?

[Arcanoxer]

Bis zu +80% ist aber ne echte Kampfansage. :eek:
Nicht jeden scheiss in ein .pdf glauben schenken.

[dargo]

Jetzt kommen die Experten. :facepalm:

[Arcanoxer]

Ich möchte dir doch nur die Enttäuschung ersparen. :comfort:
In Star Swarm possible... *shrug*

[Unicous]

Arcanoxer der Troll trollt mal wieder. What else is new?:rolleyes:

Ich habe extra die Präsentation verlinkt, man kann da bequem hinspulen.

[Arcanoxer]

Arcanoxer der Troll trollt mal wieder. What else is new?:rolleyes:

Ich habe extra die Präsentation verlinkt, man kann da bequem hinspulen.
Analyst im Haus. *hattip*

Beantworte mir doch mal eines: Wenn es wirklich ein 80% Performance Bonus bescheren soll, warum ist es auf fucking Seite 43 untergebracht und nicht auf den Cover? :freak:

[Nightspider]

Was ist bei "bis zu" so unverstädlich?

Das du nicht verstehst, dass das nichts so besonderes ist?

[Unicous]

Analyst im Haus. *hattip*

Beantworte mir doch mal eines: Wenn es wirklich ein 80% Performance Bonus bescheren soll, warum ist es auf fucking Seite 43 untergebracht und nicht auf den Cover? :freak:

Ich weiß nicht was "den Cover" ist, aber da du dir nicht einmal die Mühe machst und den verlinkten Vortrag für ein paar Minuten anhörst, erspare ich mir im Gegenzug dir zu erklären was gemeint ist.

[Arcanoxer]

Ich weiß nicht was "den Cover" ist, aber da du dir nicht einmal die Mühe machst und den verlinkten Vortrag für ein paar Minuten anhörst, erspare ich mir im Gegenzug dir zu erklären was gemeint ist.
Du glaubst also auch an die 80%?

[Unicous]

Du glaubst also auch an die 80%?

Da du weiterhin so trollig fragst, gehe ich davon aus, dass du weiterhin nicht in der Lage bist, auf einen Link zu klicken und den Worten anderer Menschen zu lauschen.

Traurig.:(

[Effe]

Es geht um AMD, was erwartest Du von ihm?

[dargo]

Ich erwarte von ihm auch nichts wenn es nicht um AMD geht. ;)

[Arcanoxer]

Hat wer von den Experten hier noch die ersten Mantle Spekulationen im Kopf?
Ich möchte nun nicht mit "ich habe es euch aber gesagt" kommen...

Aber einige Lehnen sich hier wieder mit frühzeitigen Behauptungen aus den Fenster. *yawn*
Alte Leier.

[SaschaW]

Hat wer von den Experten hier noch die ersten Mantle Spekulationen im Kopf?
Ich möchte nun nicht mit "ich habe es euch aber gesagt" kommen...

Steht ja alles in der Programming Guide :
Mantle API defines two queue types: a universal queue (GR_QUEUE_UNIVERSAL) and an
asynchronous compute queue (GR_QUEUE_COMPUTE). Other queue types, such as DMA and so on
are exposed through extensions. There is at least one universal queue available for the Mantle
device; other queues are optional.

D.h. man braucht min. 2 zwei Queues (einmal für Graphics und einmal für Compute) um ASync Compute nutzen zu können.

Wenn es nur eine Queue gibt die sowohl Graphics als auch Compute kann (auch möglich), dann gibt es natürlich kein Async Compute.

Unter Vulkan wird dass dann auch so sein.

Wie das auf AMD und Mantle mit den verfügbaren Queues je nach GPU aussieht kann ich nix sagen.

Zu Vulkan und der GPU die ich verwenden darf ich nix sagen (NDA).

Wie performant dass ist hängt dann natürlich auch stark von den Randbedingungen ab. Um die Synchronisation der Queues (egal ob Mantle oder Vulkan) muss sich der Entwickler kümmern. Idealerweise so dass keine der Queues stallt.

[Arcanoxer]

@SaschaW
Der nutzen von Async Compute ist außer Frage gestellt, nur der realistische Performancezuwachs wird meinerseits angezweifelt.

Was ist deine Meinung zur topic? :confused:

http://fs1.directupload.net/images/150911/r96up85j.png (http://www.directupload.net)

[SaschaW]

@SaschaW
Der nutzen von Async Compute ist außer Frage gestellt, nur der realistische Performancezuwachs wird meinerseits angezweifelt.

Was ist deine Meinung zur topic? :confused:

http://fs1.directupload.net/images/150911/r96up85j.png (http://www.directupload.net)

Wie gesagt kommt das stark auf das Szenario an. Der Screencap zeigt das aber ja doch schon sehr schön. Das was da in der Compute Queue asynchron zur Graphics Queue läuft kann durchaus einiges an Zeit kosten, das ist dann Zeit die nicht mehr auf die Framezeit drückt.

Wenn man dann auch noch Physik mit Compute Shadern realisiert dürfte das ordentlich was bringen. Wie gesagt muss man halt selbst synchronisieren, also dafür sorgen dass die Compute Ergebenis der Graphics Queue zur Verfügung stehen wenn man sie dort benötigt. Das sind die roten Blöcke auf dem Screenshot. Je mehr man da parallelisiert desto größer wird i.d.R. der Reibungsverlust durch die Synchronisation. Deshalb gibt es ja Sachen wie Tasksheduler. Aber keine Ahnung ob es überhaupt einen IHV gibt der mehr als jeweils eine Compute und eine Graphics Queue anbietet. Im Prinzip ist das ja nicht viel anders als Multi-Threading auf der GPU, da hängt de Performancezuwachs auch sehr stark vom Entwickler und den Randbedingungen ab. Nicht alles lässt sich leicht parallelisieren, das gilt sowohl für CPU als auch für die GPU.

Aber wenn das nur ein IHV kann (also AMD) und der überwiegende Rest nicht, dann wird die Adaption eher gering bleibt.

[Arcanoxer]

Aber wenn das nur ein IHV kann (also AMD) und der überwiegende Rest nicht, dann wird die Adaption eher gering bleibt.Genau das war ja auch das Problem von Mantle, was zum Glück kein Vulkan Anhängsel ist.*

*Ich meine nicht Mantle, sondern den cross-platform support.

[Unicous]

Nur der Vollständigkeit halber:

AMD hat auf der XDC2015 ihren Vulkan Treiber vorgestellt.

http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf

[Lord_X]

^^ Also wenn ich das richtig verstanden habe, dann wird der Vulkan Treiber von AMD unter Linux komplett Open Source! Wow

[iuno]

Ja allerdings nicht sofort und nicht upstream.
Interessant ist die Aussage, sie nehmen den existierenden, CS Vulkan Treiber und öffnen ihn.
Was mich aber schon wieder verwirrt sind die Codenamen: volcanic islands = carrizo, tonga, iceland. Und was sind sea Islands?

[Locuza]

Southern Islands = Tahiti, Pitcairn, Cape Verde usw. (GCN Gen 1)
Sea Islands = Kabini, Kaveri, Bonaire, Hawaii (GCN Gen 2)
Volcanic Islands was du genannt hast. (GCN Gen 3)

[iuno]

Danke. Hatte schon wieder etwas durcheinander geschmissen. Aber ich dachte amdgpu gibt es nur für Gen. 3... hat die experimentelle Unterstützung von sea islands in 4.2 noch Aussicht auf Weiteretwicklung? Und welcher chip ist iceland, btw?

[Locuza]

Im Prinzip ja.
Anscheinend "darf" man nicht Zwei-Kernel Module für ein Device haben.
Entsprechend werden die älteren GPUs weiterhin von Radeon unterstützt und beginnend ab GCN Gen 3 von AMDGPU.
Manuell lässt sich der neue Kernel-Treiber aber auch für GCN Gen 2 aktivieren, was dann aber nicht "offiziell" gewartet wird.

Keine Ahnung welcher Chip Iceland ist bzw. überhaupt verkauft wird und wenn ja, an wen?
Es ist ein low-end Chip und laut den Einträgen in Linux Treibern auch technisch relativ alt.
Irgendwo im Forum gab es eine Übersicht zu der ALU-Version, Memory-Controller, Display-Controller, UVD/VCE usw.

[d2kx]

Nicht nur Vulkan wird geöffnet, auch PowerPlay und spätere weitere Komponenten aus dem Catalyst, in die viele Jahre Arbeit investiert wurde. Andere Bestandteile, wie Videodekodierung (UVD) und Videoenkodierung (VCE) haben jetzt schon eine bessere Implementation im neuen Open Source-Stack als im Catalyst, daher ist das an anderer Stelle nicht erforderlich.

Den Talk gibt es es jetzt auch als Video ♥ Thema ist die Zukunft von AMDs Treiberstrategie als Ganzes, nicht nur bezogen auf Vulkan.

lXi0ByVTFyY

[iuno]

Ja, stimmt, da hatte mal jemand was aus dem source code zusammengesucht edit: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/vi.c
Bzgl. Iceland sagt der da im Video (06:09)
Iceland, which is one of those power express (:confused:) chips with no display - however - on it.
Zu Sea Islands sagt er sinngemäß, das es halt da ist, weil sie ja mit irgendwas arbeiten mussten, aber eine extra Option braucht und vielleicht auch wieder rausfliegt. Man muss also wohl den Kernel mit der option compilen damit man eine Sea Islands Karte mit amdgpu nutzen kann. Das dachte ich mir, die Folie hat mich nur stutzig gemacht... Schade, aber auch verständlich. Mit dem Neuanfang sind sie auf dem richtigen Weg, weiter so ;)


Nicht nur Vulkan wird geöffnet [...]
Ja, aber das ist der Vulkan-Thread und ich habe das nur so herausgestellt weil da steht, dass sie bereits einen closed source Linux Treiber dafür haben.
Danke fürs Video ;)

[-/\-CruNcher-/\-]

Sehr interessantes Interview :)

PAnyQkYe_Pw

[StefanV]

Und was sagen sie da?

[samm]

Interessanter als das Linaro-Interview finde ich die gesammelten Siggraph 2015 Talks von Khronos (https://www.youtube.com/watch?v=quNsdYfWXfM)

Btw: Windows XP :D Nativer Support auf relevanten Linuxen (auch Andriod) - was genau sie mit "Server Side" Support meinen, ist mir nicht ganz klar. Ist nicht Open-CL die Compute Seite, sondern ist auch Vulkan direkt für Compute angedacht?
Haskel, C#, ... --> Spir V :) Das wird lustige neue Shader geben :)

[SaschaW]

Ist nicht Open-CL die Compute Seite, sondern ist auch Vulkan direkt für Compute angedacht
Vulkan hat auch compute Shader (glsl). Idealerweise hat man dann eine separate Queue für Graphics und eine für Compute. Kommt dann aber auf die GPU an.
Eine Vulkan Implementation die nur compute queues anbietet ist aber auch denkbar. Ob das ggü OpenCL Sinn macht sei mal dahin gestellt.

[Achill]

Vulkan hat auch compute Shader (glsl). Idealerweise hat man dann eine separate Queue für Graphics und eine für Compute. Kommt dann aber auf die GPU an.
Eine Vulkan Implementation die nur compute queues anbietet ist aber auch denkbar. Ob das ggü OpenCL Sinn macht sei mal dahin gestellt.

Wenn ich es richtig verstehe, dann läuft es nach Seite 13 der "Vulkan Overview" (https://www.khronos.org/assets/uploads/developers/library/overview/vulkan-overview.pdf)-Folien alles auf SPIR-V raus - es wird also Polyglot wie schon lange im Web-/Mobile-Bereich. Das Team nimmt die Sprache, die am besten das Problem löst und vom Team beherrscht wird.

Generell sehr gut finde ich an der Vulkan-Entwicklung die Bekennung zu Open Source, als Java- & Web-Entwickler will ich nie wieder zurück in die Zeiten, wo man nur compilierte Bibliotheken bekommen hat und weh irgend etwas ging nicht wie spezifiziert ...

[SaschaW]

Wenn ich es richtig verstehe, dann läuft es nach Seite 13 der "Vulkan Overview" (https://www.khronos.org/assets/uploads/developers/library/overview/vulkan-overview.pdf)-Folien alles auf SPIR-V raus - es wird also Polyglot wie schon lange im Web-/Mobile-Bereich. Das Team nimmt die Sprache, die am besten das Problem löst und vom Team beherrscht wird.


Ja, Vulkan kann direkt SPIR-V. Das erzeugt man mit dem glslang Referenzcompiler aus GLSL-Shadern.

Da Vulkan aber auch Extensions gibt wird, kann es durchaus auch IHVs geben die über eine Extension das direkte Laden von GLSL erlauben. Wäre dann aber eher für die Entwicklung interessant, weil SPIR-V sehr viele Vorteile hat.

Generell sehr gut finde ich an der Vulkan-Entwicklung die Bekennung zu Open Source, als Java- & Web-Entwickler will ich nie wieder zurück in die Zeiten, wo man nur compilierte Bibliotheken bekommen hat und weh irgend etwas ging nicht wie spezifiziert ...

Ich (persönlich) finde v.a. gut wen man dafür (und mit) ins Boot geholt hat. Die Zusammensetzung der Personengruppe die Vulkan mit entwickeln darf ist sehr gut gewählt, und das merkt man der API auch an. Statt zu sagen "hier habt ihr eine neue API" wird Vulkan aktiv mit (und teilweise) von den zukünftigen Nutzern entwickelt. Und dazu zählen diesmal auch Leute die nicht irgendwo bei IHVs oder ISVs sitzen ;)
Das wird dann auch direkt Auswirkungen auf das Ökosystem rund um Vulkan haben. Die ganzen Libs die man jetzt rund um OpenGL nutzt will man gerne direkt am Start haben, genauso wie Beispiele, Tutorials, etc. und dementsprechend setzt sich die Personengruppen auch zusammen.

[Achill]

[...]
Ich (persönlich) finde v.a. gut wen man dafür (und mit) ins Boot geholt hat. Die Zusammensetzung der Personengruppe die Vulkan mit entwickeln darf ist sehr gut gewählt, und das merkt man der API auch an. Statt zu sagen "hier habt ihr eine neue API" wird Vulkan aktiv mit (und teilweise) von den zukünftigen Nutzern entwickelt. Und dazu zählen diesmal auch Leute die nicht irgendwo bei IHVs oder ISVs sitzen ;)
Das wird dann auch direkt Auswirkungen auf das Ökosystem rund um Vulkan haben. Die ganzen Libs die man jetzt rund um OpenGL nutzt will man gerne direkt am Start haben, genauso wie Beispiele, Tutorials, etc. und dementsprechend setzt sich die Personengruppen auch zusammen.


Ja, das ist für mich auch gelebte OpenSource und eins der Effekte die entstehen sollten... :)

[-/\-CruNcher-/\-]

Sahen wir hier vieleicht schon Vulkan bei den vollen 20W ? ;)

LzHRWb6PPzs

[Screemer]

Sahen wir hier vieleicht schon Vulkan bei den vollen 20W ? ;)

http://youtu.be/LzHRWb6PPzs

Alter das Video ist vom 3.3.15. du glaubst doch wohl selbst nicht, das die da laufende vulcan-treiber für android/tegra hatten, oder?

[-/\-CruNcher-/\-]

Naja das verhalten von dem presenter ist schon komisch wie als (NDA kann ich nicht sagen, schnell ausweichen)
Und wieso sollte es unmöglich sein es macht sogar sinn wenn Nvidia es als ersten Shield Vulkan port releasen würde ;)

OpenGL ES 3.1 mit GLSL nicht unvorstellbar aber sinn mit Vulkan wo es vor der Tür stand hmm

Klar ist mit Pascal werden sie schon sehr nah bei der PS4 und Xbox One ankommen ;)

Das scheint Tony Tamasi zu sein der es dem Ryan Shrout da präsentiert ;)

http://nvidianews.nvidia.com/bios/tony-tamasi

Gut nicht ungewöhnlich wenn er es wirklich nicht wüsste ;)

Zumal hat Nvidia es auf der Siggraph auf ihrem X1 Tablet ja auch gedemoed ;)

https://youtu.be/quNsdYfWXfM?t=5840

Die ganze sache mit den Demos ging aber drunter und drüber wegen den Projector Sync Problemen und hier in dem Stream ist auch was komischerweise komplett verschwunden ;)

[Novum]

Die Shield-Tablets koennen normales OpenGL 4.5

[deekey777]

Crysis 3 auf der Shield scheint eh verstorben zu sein.

[iuno]

Viper hat im SC Thread etwas interessantes gepostet:
Viper;10795783']Chris Roberts spricht über DX12, Vulkan und über die Implementierung in Star Citizen:

Transcript:
http://www.gamersnexus.net/gg/2114-chris-roberts-star-citizen-on-dx12-vulkan-and-tech/Page-2

Video:
http://youtu.be/XD9_L5o4mhQ

Schade, bei einem so ambitionierten Projekt wäre es schön gewesen, ganz auf den alten Kram zu verzichten und es nur mit Vulkan/DX12 zu bringen :P

[iuno]

imagination macht 5 webinare zum Thema Vulkan. Das ganze läuft über google+ und startet am 26. Später kommen die Videos auch auf YouTube:
http://blog.imgtec.com/powervr/5-new-webinars-on-the-vulkan-api

[iuno]

Im Nvidia Treiber gibt es erste Anzeichen für Vulkan:
http://forums.laptopvideo2go.com/topic/31826-nvidia-geforce-driver-35866-adds-vulkan-pascal-and-volta-support/

Und außerdem für Pascal & Volta ;)

[Kartenlehrling]

........... (ohne Worte)

https://www.youtube.com/watch?v=BeRDavjlEyo
OsmoEngine v0.64 Ultra Realistic Water Demo 1

[Unicous]

Was für dreckiges Brackwasser. 2/10, would not swim.:rolleyes:



;)

[-/\-CruNcher-/\-]

Das ist vergleichbar mit dem Resultat was Nvidia zusamen mit den Russichen War Thunder Entwicklern aus Waveworks geholt hat ;)
innerhalb dererer Dagor Engine Target DX 11

https://youtu.be/cx1e97YSIFU?t=92


es wäre kein großer Aufwand für Nvidias Team das selbe Ergebnis wie diese Osmo Engine zu erreichen wenn sie das Budget zur verfügung gehabt hätten innerhalb des Render Targets.

[Nightspider]

Die Grafik hätte ich gerne in einem BF1942 Remake und dann richtig schön Omaha Beach daddeln. :D

[iuno]

Das ist das vergleichbar mit dem Resultat was Nvidia zusamen mit den Russichen War Thunder Entwicklern aus Waveworks geholt hat ;)
ja, wenn Aepfel mit Birnen vergleichbar sind, schon

es wäre kein großer Aufwand für Nvidias Team das selbe Ergebnis wie diese Osmo Engine zu erreichen wenn sie das Budget zur verfügung gehabt hätten innerhalb des Render Targets.
Sie haben es aber nicht gemacht und das hier ist nur eine Demo, kein Spiel. Noch dazu hat man keine Ahnung ueber den Ersteller und die Engine, oder ob das Video ueberhaupt 'echt' ist. Wer steckt dahinter und wie kommt er/sie schon an Vulkan Treiber?

[-/\-CruNcher-/\-]

Natürlich ist ein GPU unabhängigs Performance Ergebnis immer eine super sache :)

Naja eine sache ist Auffällig der Bezug zu ARMA ;)

Osmo Engine vielleicht der neue Engine Name einer neuen ARMA Engine und "Wüstenfuchs" vielleicht ein Bohemia Interactive Engine Dev.

Bohemia Interactive würd ich so ein Ergebnis zutrauen :)

4zI48bWL-XE

Hier erkennt man jedenfalls einige Artifiziele sachen im Ergebnis, selbst bei der schlechten Video Kompression

Hier tretten diese Probleme allerdings nicht so in Erscheinung

QJmh_9d6ZWQ

Puhh doch schon etwas Brainfuck könnte auch ein Real Video sein

eher altes VHS Video das zudem im oberen auch noch Zeit manipuliert wurde.

Was erhofen sich leute von sowas ?


Ein ARMA Fan der Bohemias Engine vom resultat mag und mal dachte mit dem Hirn anderer zu spielen ? ;)

Hätte es fast geschluckt aus meinen eigenen Ergebnisen heraus vor allem in solchen limitierten Szenarien ;)

so ein schönes Chaotic Movement artificial hinzubekommen (algorithmus) ist aber garnicht einfach , Nvidia trau ich das durchaus zu ;)

[Kartenlehrling]

Ich hatte immer noch gehofft das es noch dieses Jahr wird, das scheint wohl vom Tisch.

Basemark GPU Vulkan will be commercially available in Q2, 2016 for both mobile and PC platforms.

http://www.basemark.com/2015/11/10/basemark-extends-its-benchmarking-lead-with-a-vulkan-performance-test/

[SaschaW]

Ich hatte immer noch gehofft das es noch dieses Jahr wird, das scheint wohl vom Tisch.



http://www.basemark.com/2015/11/10/basemark-extends-its-benchmarking-lead-with-a-vulkan-performance-test/

2015 hat ja noch ein paar Wochen, wobei sich Erfahrungsgemäß grade in der zweiten Dezemberwoche wenig tut.

Aber entsprechend der gesteckten Ziele (Alle IHVs, Mobil, Desktop, mehrere Betriebssysteme, viele ISVs) und der recht großen Gruppe an Personen die an der Sache beteiligt sind machts auch nix wenn die API erst im Q1/Q2 2016 kommt.

Täte der Sache nicht gut wenn man das jetzt nur wegen der Ansage "2015" raushaut und dann mit unfertigen Treibern und Makeln in der API startet. Es geht ja nicht nur darum eine neue API zu platzieren, sondern um ein ganzes Ökosystem. Auf Basis von Vulkan wird irgendwann ja auch, wie schon bei OpenGL, ein Safety Cricital Profile kommen, und auch alles rundherum muss passen. Anders als bei OpenGL wird es von Anfang an ein SDK geben. Ein guter Start ist hier wichtiger als ein fixer Termin, und wenn man alles richtig macht dann hat man die Chance MS mit seiner DX12 "ein-OS" Strategie komplett ins Abseits zu schießen.

Vulkan soll ja immerhin ein paar Jahr(zent)e Bestand haben, und da darf man sich für ein solides Grundgerüst auch mal Zeit lassen. Zumal die API jetzt schon sehr schick aussieht.

[iuno]

Zumal die API jetzt schon sehr schick aussieht.
Hast du schon damit gearbeitet? Falls ja, kannst du eine Einschaetzung zu den obigen Videos abgeben?

[SaschaW]

Hast du schon damit gearbeitet? Falls ja, kannst du eine Einschaetzung zu den obigen Videos abgeben?

Ja, habe ich (habe dazu auch was gebloggt (http://www.saschawillems.de/?p=1886), wobei das schon drei Monate her ist).

Zu den Videos kann ich nix sagen, bin mir aber sicher dass zumindest das untere ein Fake ist. Ansonsten habe ich halt ein paar NDAs unterzeichnet und kann daher keine Details nennen (außer dem was bekannt ist).

[Chris Lux]

Hast du schon damit gearbeitet? Falls ja, kannst du eine Einschaetzung zu den obigen Videos abgeben?
Was hat die API mit den Videos zu tun?

[Novum]

Viele Leute denken bestimmte Effekte seien Bestandteil der API.

[iuno]

Was für ein Unsinn :rolleyes:
Es könnte ja sein, dass er weiß, von wem das stammen soll, oder er irgendwas über das Projekt weiß. Ich wollte wissen, ob es überhaupt möglich ist, im aktuellen Stadium mit dem SDK und den Treibern, die man ja nur als insider bekommt, so eine Demo herzustellen. Die Frage hat also wohl weitaus mehr mit dem Thema zu tun als eure Posts zusammen. Ich verstehe aber, dass ich meine Fragen wieder spezifischer stellen sollte, da sonst gleich wieder diejenigen mit Beißreflex anspringen, die überhaupt nicht gefragt sind :P

[SaschaW]

Ich wollte wissen, ob es überhaupt möglich ist, im aktuellen Stadium mit dem SDK und den Treibern, die man ja nur als insider bekommt, so eine Demo herzustellen.

Vulkan entspricht den aktuellen OpenGL und GLSL-Versionen (auf entsprechender Hardware), also kann man damit alles machen was auch mit der aktuellsten OpenGL Version möglich ist. Auch komplexe Demos die die komplette Shaderpipeline nutzen. Also Vertex, Geometry, Tessellation Control, Tessellation Eval und Fragment Shader.

Edit : Compute shader natürlich auch.

[Gandharva]

Vulkan-Treiber-Experten wechseln zu Googles Android-Team

http://www.golem.de/news/lunarg-vulkan-treiber-experten-wechseln-zu-googles-android-team-1511-117424.html

[iuno]

@SaschaW: danke
@Gandharva: sehe ich nicht problematisch, sofern google offen damit umgeht. Immerhin hat die Firma wahnsinnig viel Ressourcen und wohl mit am meisten Interesse, dass das mit den mobile devices was wird.

[Unicous]

Zumal die ja auch an Vulkan-Treibern für Google arbeiten könnten.;)

[SaschaW]

Zumal die ja auch an Vulkan-Treibern für Google arbeiten könnten.;)

An Treibern direkt eher nicht. Die macht der jeweilige IHV, und ich nehme an dass alle bekannten Hersteller mobiler GPUs bereits Treiber haben. PowerVR geht damit ja ziemlich offen um. Deren Vulkan Sessions sind übrigens sehr interessant, am 19.11 (17:00) ist die nächste.

[Troyan]

Google ist für die Treiber ihrer Produkte verantwortlich bzw. hat ein Wörtchen mitzureden. Die haben auch kein OpenGL für das Nexus 9 veröffentlicht...

[Gandharva]

Google ist sicher nicht für die Treiber verantwortlich. Die kommen beim N9 von NVidia. Allerdings sind sie für den EGL Layer in Android mitverantwortlich. Und dort liegt bzgl. N9 der Hund begraben. An sowas werden sie vermutlich die Leute von LunarG setzen.

Der EGL API Layer in Android ist offenbar extrem rückständig.

https://code.google.com/p/android/issues/detail?id=80882

https://android.googlesource.com/platform/frameworks/native/+/master/opengl/libs/EGL/eglApi.cpp

[SaschaW]

Ich glaube nicht dass man Vulkan (auf Android) via EGL anbinden wird. Da wird es (wie unter Windows und Linux) auch eine eigene Anbindung (Extension) für das Präsentieren der Images an das darunterliegende Fenstersystem geben. Allein schon wegen der Queues. Ich nehme an die LunarG-Leute die zu Google gehen, werden dann am Anfang eine entsprechende Platform Extension entwickeln.

EGL ist eh so ne Sache. Wundert mich z.B. immer wieder warum AMD OpenGL ES auf dem Desktop nur via EGL exponieren, und nicht wie der Rest der IHV-Welt über die passenden OpenGL Extensions. Hatte da mal ne Testversion für meinen OpenGL Hardware Viewer gebaut der EGL benutzt hat, aber das war nicht schick und hats nicht ins finale Produkt geschafft.

(https://www.khronos.org/assets/uploads/developers/library/overview/Khronos-Press-Briefing-SIGGRAPH_Aug15.pdf, Seite 14).

[Gandharva]

Ich glaube nicht dass man Vulkan (auf Android) via EGL anbinden wird.
Das habe ich auch nie behauptet. Aber auch Vulkan wird einen OS Layer brauchen in Android und wenn der genauso madig implementiert wird wie es offensichtlich bei EGL der Fall ist... Ich denke du verstehst worauf ich hinaus will wenn ich schreibe "an sowas". Die Leute von LunarG kennen sich ja nicht nur mit Vulkan aus.

[SaschaW]

Das habe ich auch nie behauptet. Aber auch Vulkan wird einen OS Layer brauchen in Android und wenn der genauso madig implementiert wird wie es offensichtlich bei EGL der Fall ist... Ich denke du verstehst worauf ich hinaus will wenn ich schreibe "an sowas". Die Leute von LunarG kennen sich ja nicht nur mit Vulkan aus.

Ja, ich verstehe worauf du hinaus willst. Weder mit OpenGL ES noch mit OpenGL ist die Anbindung an das darunterliegende Windowing System schick.

Das sieht mit Vulkan aber anders aus (siehe Slides). Da ist das besser abstrahiert, der Code für die Swapchain, also die "Liste der Bilder" (man entschuldige meine Vereinfachung ;)) die man dem Betriebssystem präsentiert ist unabhängig vom OS und über ein Flag wird dann gesteuert welche Platform man bedient. Viel schicker als der alte Kram unter OpenGL mit WGL, GLX und Co.

[Ganon]

Erster Schritt ist getan, OpenCL 2.1 und SPIR-V 1.0 Spezifikation sind draußen:

https://www.khronos.org/news/press/khronos-releases-opencl-2.1-and-spir-v-1.0-specifications-for-heterogeneous

Fehlt nicht mehr viel zu Vulkan :D

[SaschaW]

Mindestens genau so schick : https://github.com/KhronosGroup/Khronosdotorg.git

Gleich mal geforkt :)

[Arcanoxer]

What You Need To Know About SPIR-V 1.0 (phoronix) (http://phoronix.com/scan.php?page=news_item&px=SPIR-V-1.0-Details)

[SaschaW]

What You Need To Know About SPIR-V 1.0 (phoronix) (http://phoronix.com/scan.php?page=news_item&px=SPIR-V-1.0-Details)

Mit dem reference compiler (https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/) kann man übrigens schon länger SPIR-V aus GLSL erzeugen. Ohne Zugang zu Vulkan kann man damit zwar aktuell noch wenig anfangen, aber wer sich für SPIR-V interessiert kann schonmal damit rumspielen und evtl. auch schon seine Toolchains darauf umstellen.

[Ganon]

Ich hoffe einfach nur, dass mit OpenCL 2.1, durch den offiziellen Compiler und SPIR-V, Blender mit ihrem OpenCL Cycles Kernel besser voran kommt. Natürlich müssen da erst mal von NVidia und AMD die Treiber kommen. Und ich hoffe mal, dass NVidia da nicht noch wieder Jahre für braucht. Für OpenCL 1.2 haben sie ja auch 3 Jahre gebraucht und OpenCL 2.0 können sie noch gar nicht.

[Kartenlehrling]

http://www.think-silicon.com/docs/AN_TSI_VULKAN_November_12_2015.pdf
VulkanTM on Think Silicon’s NEMA-GPU SERIES

[M4xw0lf]

http://blog.mecheye.net/2015/12/why-im-excited-for-vulkan/
Über OpenGL,Vulkan, DX12 und Treiberspielchen.

[tdon]

Khronos Confirms No Vulkan For This Year + Some Exclusive Phoronix Details (http://www.phoronix.com/scan.php?page=news_item&px=Khronos-Confirms-No-Vulkan)

[Locuza]

"I can confirm that the spec was finished a couple of weeks ago and is now going through the (longish) Khronos legal review process. I'm not allowed to talk about when it might go public, but I will say that the gating factor for release will be availability of product-quality implementations. That's a pretty high bar, given that the API has changed a lot since GDC and, well, end of year holidays are hell on engineering schedules. Still, it won't be *very* long..." It's interesting to here that the API has evolved a lot since GDC (August) considering earlier in the summer we had heard that the API was effectively finalized.

Hoffentlich positiv entwickelt, ohne performancekritische Sachen wieder herauszunehmen, um es einfacher zu machen.

[Nightspider]

Ich gehe mal stark davon aus das Vulkan einen noch tieferen low level Zugriff auf die Hardware ermöglicht im Vergleich zu DX12.
Sowas in der Art laß ich ja schon neulich von den Async Compute Engines welche mit AMDs Tools noch besser genutzt werden können als mit DX12 oder so ähnlich.

[Locuza]

Im Grunde gibt es viele Möglichkeiten noch mehr als DX12 anzubieten.
Programmierbare MSAA-Samples-Points (Kam schon offiziell als Erweiterung für OGL 4.5 hinzu).
Auf Compute Ebene könnte man eine Menge mit SPIR-V und einem C++ Subset machen.
Daran sind sicher viele Entwickler interessiert.
Auch die ganzen bisherigen OpenCL Features wie GPU-side-enqueue, cross-lane-operations etc.

DX12 hat in der Hinsicht nichts neues gebracht.

[SaschaW]

Hoffentlich positiv entwickelt, ohne performancekritische Sachen wieder herauszunehmen, um es einfacher zu machen.

Ja, ich persönlich finde die API jetzt richtig schick und v.a. sehr konsistent. Also ganz anders als dass was OpenGL inzwischen ist ;)

Dank SPIR-V gibt es jetzt auch ein richtig geiles Feature dass die Nutzung von Shadern nochmal richtig aufwertet und einfacher macht : https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_entry_point_and_execution_model :)

[Locuza]

Ich habe schon lange nicht mehr bei Phoronix vorbei geschaut und scheinbar niemand anderes?
Die neuste Linux-News ist schon ein Tag alt und ich habe es nirgendwo anders bisher gelesen. (Wo ich geschaut habe :P)

The Radeon Vulkan Linux support is ready to launch as soon as Khronos rolls out the specification... A lot of developers have already been testing their Vulkan driver and things appear good on that front. But as previously reported, their Vulkan driver will be closed-source at launch and open-sourced later. They may also provide the code to distribution partners early for integration (prior to a fully-blown open-source project).
http://www.phoronix.com/scan.php?page=article&item=amdgpu-2016-details&num=1

Gut zu hören, weil AMD war ziemlich ruhig was das Thema Vulkan anging mit konkreten Ankündigungen, obwohl es aus Mantles Kruste entspringt.

[iuno]

Ich habe schon lange nicht mehr bei Phoronix vorbei geschaut und scheinbar niemand anderes?
Die neuste Linux-News ist schon ein Tag alt
Doch, aber das war mir keine Meldung hier wert ;)
Ist nichts wirklich neues. Dass sie schon Vulkan Treiber haben, war klar, dass er erst closed und dann open source ist, auch schon vorher so kommuniziert.

[Locuza]

Das er aber day one ready sein wird, dass war für mich eine Erleichterung.
AMD, Nvidia und Intel stehen damit schon zum Vulkan Launch bereit.

Im mobile-space hat Googel aber noch nicht angekündigt, wann Vulkan zu Android kommt?

[just4FunTA]

jetzt müsste man nur wissen wann der launch ist.

[iuno]

Nein, einen Termin gibt es nicht. Dazu hatten wir es aber auch kuerzlich im DX12 Thread. Bei Android ist Fragmentierung ja ein grosses Problem. Selbst wenn Vulkan schon in der naechsten Version ("N") drin waere, wuerde es noch relativ lange dauern, bis eine gewisse Menge an Geraeten das auch unterstuetzt.
Google Geraete waeren natuerlich vom Start dabei, sofern es Treiber von den passenden Herstellern gibt, da habe ich etwa beim Pixel mit Nvidia SoC keine Bedenken. Zu Adrenos/Malis weiss ich nichts, aber Imagination scheint durchaus stark beteiligt und bestrebt, das zu pushen.
Google I/O ist immer zum Sommerbeginn, spaetestens da gibt es vermutlich Infos zu Android N und Vulkan, falls es bereits rein kommt.

[Troyan]

Google ist verantwortlich für die Treiber für ihre Geräte. So haben sie kein OpenGL unterstützt im Gegensatz zu nVidia...

[Achill]

Google ist verantwortlich für die Treiber für ihre Geräte. So haben sie kein OpenGL unterstützt im Gegensatz zu nVidia...

Es wird doch auf Android OpenGL ES (http://developer.android.com/guide/topics/graphics/opengl.html) unterstützt. Die Treiber kommen m.W. nicht von Google sondern vom jeweiligen Hersteller des Grafikteils im Chip oder?

[SaschaW]

Es wird doch auf Android OpenGL ES (http://developer.android.com/guide/topics/graphics/opengl.html) unterstützt. Die Treiber kommen m.W. nicht von Google sondern vom jeweiligen Hersteller des Grafikteils im Chip oder?

Ja, die OpenGL ES Treiber kommen vom IHV, nicht von Google. Die stellen nur die API bereit.

Vulkan wird man auf Android also auch ohne neues OS von Google nutzen können (so wie z.B. ES mit AEP).

Bis Vulkan dann direkt als First-Class API in Android ausgeliefert wird braucht man halt nen passenden Treiber vom IHV (bzw. ein passendes Image, also angepasstes OS) und muss die API-Funktionen selbst dynamisch laden.

[ScottManDeath]

https://developer.nvidia.com/engaging-voyage-vulkan

[iuno]

Der Vulkan-Treiber von Nvidia frisst also GLSL, so war das aber nicht gedacht... :uponder:

[Novum]

Solange er auch SPIR-V unterstützt ist das kein Problem. Niemand kann verhindern, dass GLSL als Extension auch verwendet werden kann.

[SaschaW]

Solange er auch SPIR-V unterstützt ist das kein Problem. Niemand kann verhindern, dass GLSL als Extension auch verwendet werden kann.

SPIR-V muss unterstützt werden. Dass GLSL auch direkte Übergabe von GLSL anbietet ist ein Bonus. Das ist beim Entwickeln manchmal ganz praktisch, da man nicht dauernd umwandeln muss.

Eine Extension dafür wird es aber wie du sagst vermutlich eh irgendwann geben.

[iuno]

Natuerlich kann und will es niemand verhindern. Das klang mglw. auch negativer als es sollte.
Das koennte aber durchaus zu einem Problem werden, aber ich will ja nicht schon Schwarzsehen, wenn es ueberhaupt gar keinen Grund dazu gibt.

[SaschaW]

Natuerlich kann und will es niemand verhindern. Das klang mglw. auch negativer als es sollte.
Das koennte aber durchaus zu einem Problem werden, aber ich will ja nicht schon Schwarzsehen, wenn es ueberhaupt gar keinen Grund dazu gibt.

Ich kann mir nicht vorstellen dass jemand Produktionscode ausliefern will der bei einem IHV GLSL verwendet und beim Rest SPIR-V. Dazu hat SPIR-V zu viele Vorteile.

Beim Entwickeln ja (da ganz praktisch), aber fürs Release dann definitiv SPIR-V, auch für NV.

[iuno]

Ich auch nicht, aber darum geht es auch nicht.
Es gibt heute schon einige neuere Spiele, die auf Linux offiziell nur mit Nvidia laufen. Aber wie gesagt ;)
ich will ja nicht schon Schwarzmalen, wenn es ueberhaupt gar keinen Grund dazu gibt.

[z3ck3]

Es gibt heute schon viele Spiele, die auf Linux offiziell nur mit Nvidia laufen.

Ist das so? Welche wären das?

[iuno]

"viele" war natuerlich Bloedsinn, habe das rausgenommen. Allerdings sind es einige der neueren, groesseren Spiele. Bei der Menge an AAA-Games die fuer Linux kommen, ist das dann eben gleich ein gewisser Anteil.
Eine Liste pflege ich natuerlich nicht, aber spontan fallen mir Shadow of Mordor, Alien Isolation und das letzte Total War ein.

edit: kleine Recherche bei Steam sagt z.B. noch Borderlands: The Pre-Sequel, Borderlands 2, GRID Autosport

aber Schluss mit ot ;)

[Novum]

SPIR-V muss unterstützt werden. Dass GLSL auch direkte Übergabe von GLSL anbietet ist ein Bonus. Das ist beim Entwickeln manchmal ganz praktisch, da man nicht dauernd umwandeln muss.

Eine Extension dafür wird es aber wie du sagst vermutlich eh irgendwann geben.
Klar muss SPIR-V unterstuetzt werden. Ich wollte nur klarstellen, dass das nicht negativ ist.

Das hilft halt beim entwickeln/portieren wenn man nich durch SPIR-V muss und NVIDIA hat den Compiler ja eh schon im Treiber.

[Screemer]

AMD

AMD graphics cards are not currently supported by Middle-earth: Shadow of Mordor.

If you wish to play the game using an AMD graphics card regardless, we recommend that you update your graphics driver to AMD Catalyst version 15.7 or higher. You should be able to run the game without experiencing stability issues or graphical glitches, but you may still experience poor performance.
Das liest sich aber anders. Den rest auch ich jetzt mal nicht. Mich würde es eher wundern wenn eins der spiele nicht laufen würde.

[z3ck3]

Interessant. War mir besher gar nicht bekannt. Das AMD schlechter unter Linux performt war ja schon immer so, auch wenn sich das etwas gebessert hat. Das AMD aber glatt von den Entwicklern als "die paar Idioten die AMD unter Linux nutzen, die beachten wir gar nicht" abgewickelt wird ist mir neu gewesen. War aber eigentlich auch abzusehen, seit Valve klar gesagt hat das AMD zur Zeit keine brauchbare Hardware für Linuxgaming ist. Das kann sich nur ändern wenn AMD aus dem Quark kommt.

[fondness]

Vulkan Session von AMD:
http://schedule.gdconf.com/session/vulkan-fast-paths-presented-by-amd

[iuno]

Das liest sich aber anders. Den rest auch ich jetzt mal nicht. Mich würde es eher wundern wenn eins der spiele nicht laufen würde.
Ich habe auch nicht behauptet, es wuerde nicht laufen sondern, es sei nicht offiziell unterstuetzt. Tatsaechlich "laeuft" Mordor sogar mit radeonsi, wohingegen es zum release iirc gar nicht (auch nicht mit fglrx) ging.

@fondness: schoen es geht los. Langsam hat jeder vendor was zu melden, dann kann es wohl nicht mehr lange dauern - wobei die gdc ja erst im Maerz ist ;)

Das kann sich nur ändern wenn AMD aus dem Quark kommt.
Daran wird sich imho nichts mehr aendern. Es hat zu viele Gruende und lohnt zu wenig. Man kann nur hoffen, dass sie mit Vulkan direkt einen sauberen Start hinkriegen, plattformuebergreifend.
btw: Anders sieht es aus, wenn man auf freie Treiber setzt, denn dann ist Nvidia quasi keine Alternative unter Linux. Da geht nur Intel, wo die Treiber sehr gut sind, aber die Hardware sehr schwach, oder eben AMD, wo die freien Treiber gut - aber langsam (und nur voll bis OGL 4.1 unterstuetzen) und die Hardware dafuer bedeutend besser ist. Mit Windows ist das aber nicht zu vergleichen. "die paar Idioten die AMD unter Linux nutzen" tun das also eher aus Prinzip, aber das ist jetzt wirklich zu weit vom Thema.

[Novum]

AMD hat wenigstens Open-Source-Treiber. Die NVIDIA-Binaries sind dauernd mit den letzten Kernels inkompatibel und jetzt mit Wayland. Man muss immer warten.

Wenn man nicht spielt auf Linux ist man auf jeden Fall mit Intel und AMD besser bedient.

[iuno]

Das habe ich ja gesagt ;)
Zudem stellt AMD den Vulkan Treiber fuer Linux auch unter eine freie Lizenz, um das Thema zurueckzuspannen. Wenn sie es schaffen (gehoert rechtlich auch einiges dazu), direkt von Anfang an, wahrscheinlich aber erst spaeter - immerhin. Der steht dann auch fuer die Nutzer des all-open stacks zur Verfuegung, wohingegen AMD auch mit der "1-Kernel-Treiber" Strategie die Spieler leider weiterhin beim Pro-Stack (amdgpu (frei) + proprietaerer OGL Treiber) sieht...

edit: AMDs Vulkan Treiber unter Linux nur mit amdgpu: http://phoronix.com/scan.php?page=news_item&px=AMDGPU-Vulkan-Driver-Only
Das war eigentlich klar, wenn man mal etwas ueber die Zukunftsplanung gesehen hat, vielleicht aber dennoch fuer den ein oder anderen neu.

Die Aussage dass alle GCN GPUs unterstuetzt werden sollen, koennte entweder falsch sein oder bedeuten, dass amdgpu doch noch der Standardtreiber fuer Sea und Southern Islands wird

edit2: Diese Aussage bezieht sich nur auf den user-space, also den Vulkan-Treiber an sich. Der wird nicht mit dem radeon-drm und damit auch nicht mit radeon an sich (Kerneltreiber) zusammenspielen. AMD verlaesst sich wohl auf die community, amdgpu support fuer aeltere Chips einzubauen, ob das realistisch ist, kann ich schwer einschaetzen, da muesste man mal dene Code genauer anschauen und sich damit auseinandersetzen. Auch inwieweit der Stand fuer Sea Islands in amdgpu 'fertig' ist, kann ich aktuell nicht beurteilen. Funktionierender Code fuer 'pre-VI' ist ja zwar in radeon da, aber der Umbau ist wohl eher nicht trivial. amdgpu muesste auch direkt zum Standard fuer die Karten werden und radeon die Unterstuetzung fallen lassen, denn verschiedene Treiber fuer dieselbe Hardware sind im Kernel nicht 'erlaubt' (ergibt ja auch keinen Sinn).
btw. im phoronix Forum gibt es auch einige Schwarzseher bzgl. der GLSL Thematik oben ;)

[Arcanoxer]

edit: AMDs Vulkan Treiber unter Linux nur mit amdgpu: http://phoronix.com/scan.php?page=news_item&px=AMDGPU-Vulkan-Driver-OnlyVulkan Support nur für GCN 1.2 oder neuer? Ouch.

Man kann es sich auch zu einfach machen.

[Kartenlehrling]

currently supports

naja ... nicht das ich mir da gross hoffung mache,
aber meine HD7970 habe ich sowieso schon in meinem hackintosh verplant, Metal scheit ja großzügiger zu sein.

[Arcanoxer]

Metal scheit ja großzügiger zu sein.Das hat doch nichts mit der API zu tun, sonder nur mit der Faulheit seitens AMD.

Die haben es wirklich früh genug gewusst und nun wieder so was halbes.

[iuno]

So einfach wie du es dir wieder machst ist es eben nicht.
Larabel hat es sich auch wieder einfach gemacht und einfach was geschrieben.
So sieht es aus: Der userspace Vulkan Treiber von AMD wird nur mit dem libdrm Modul von amdgpu zusammenspielen, das steht fest. Hier soll der Code uebrigens fuer Windows und Linux groesstenteils derselbe sein, das war ja bei OGL nie so.
amdgpu hat bereits Unterstuetzung fuer CI (GCN1.1) bereits da, ist in der standard kconfig aber deaktiviert. Wenn man sich selbst den Kernel kompiliert oder die Distributionen ihre Kernel darauf einstellen, ist das 'Problem' also schonmal geloest. Hier koennen sie nicht einfach mal die Standardkonfig problemlos umstellen, da GCN < 1.2 schon von radeon unterstuetzt werden und unterschiedliche Treiber fuer dieselbe Hardware nicht zulaessig sind. Man kann auch nicht einfach die radeon-Unterstuetzung streichen, da man sonst mit einem Kernel-update die Systeme kaputt machen wuerde, deren Pakete mit dem userspace-kram noch nicht auf amdgpu angepasst sind.
Wie gesagt, gehe ich davon aus, dass sich das 'Problem' von selbst loest, bei aktuellen Distributionen sollte es kein Problem sein, amdgpu fuer CI zu aktivieren und so selbstverstaendlich auch den kompletten amdgpu stack nutzen zu koennen.

Fuer GCN 1.0 steht noch nicht fest was passiert. Der Plan ist wie schon gesagt, Vulkan fuer alle GCN Karten anzubieten. Folgende Moeglichkeiten:
- libdrm_amdgpu wird angepasst auch mit radeon zusammenzuspielen
- amdgpu wird angepasst, auch mit GCN 1.0 zusammenzuspielen
(- die mesa/radeonsi Leute machen einen eigenen Vulkan Treiber)
ob das passiert und wann steht noch nicht fest (aber bestimmt nicht initial zum Vulkan-Release). Das ist schon eine andere Situation, als Larabel mit "Vulkan gibt es nur ab 1.2" beschreibt

[Locuza]

Der Kernel-Switch trifft nicht nur Vulkan, selbst der normale Radeon/Catalyst Treiber wird für GCN Gen 1 und 2 ab H1 für GCN1 und 2 "sterben".

Vulkan Support wird für Windows ab GCN Gen 1 gewährleistet.
Bei Linux muss man die Kernel-Sache irgendwie lösen.
Entweder den User Space Driver für den alten Radeon-Kernel anpassen oder AMDGPU für GCN1-2 downporten, was mit allen möglichen Problemen verbunden ist.

Für den Nutzer wäre es am besten, wenn AMDGPU auch GCN1-2 mit einschließt.
Dann genießt jeder das gleiche.

Edit: ninja'd by iuno

[r-or]

bridgman:
If the answer from AMD had been "we will only ever support Vulkan on the set of GPUs which are enabled by default on upstream amdgpu today" that would be different, but that's not what we said.
http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/845690-amd-s-vulkan-driver-will-only-work-with-the-amdgpu-kernel-driver?p=845755#post845755

-> schätzungsweise wird mittelfristig radeonsi zu amdgpu portiert werden?

[iuno]

radeonsi laeuft schon zusammen mit amdgpu/libdrm_amdgpu. sonst wuerde ja die Beschleunigung mit tonga/fiji ueberhaupt nicht funktionieren. gallium/radeonsi ist ja auch der offizielle userspace-Standard fuer den all-open stack fuer aktuelle und zukuenftige Karten.
Das hat aber mit bridgmans Aussage wenig zu tun. Verwechselst du vielleicht radeon und radeonsi?

[Novum]

bridgman:

http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/845690-amd-s-vulkan-driver-will-only-work-with-the-amdgpu-kernel-driver?p=845755#post845755

-> schätzungsweise wird mittelfristig radeonsi zu amdgpu portiert werden?
Sehr wahrscheinlich. Die Aenderungen duerften nicht so gross sein um auch aeltere GCN-GPUs zu unterstuetzen.

[r-or]

radeonsi laeuft schon zusammen mit amdgpu/libdrm_amdgpu. sonst wuerde ja die Beschleunigung mit tonga/fiji ueberhaupt nicht funktionieren. gallium/radeonsi ist ja auch der offizielle userspace-Standard fuer den all-open stack fuer aktuelle und zukuenftige Karten.
Das hat aber mit bridgmans Aussage wenig zu tun. Verwechselst du vielleicht radeon und radeonsi?
Statt radeonsi meinte ich Southern Islands + Sea Islands. Also der Part von GCN, welcher (noch?) nicht von amdgpu unterstuetzt wird. Habe mich falsch ausgedrueckt.

[Stebs]

Statt radeonsi meinte ich Southern Islands + Sea Islands. Also der Part von GCN, welcher (noch?) nicht von amdgpu unterstuetzt wird. Habe mich falsch ausgedrueckt.Nochmal als Zusammenfassung: Sea Islands (oft CI abgekürzt, die Karten mit GCN 1.1) wird von amdgpu ja schon unterstützt (und damit Vulkan), nur nicht per default, da es dafür ja noch den herkömmlichen Radeon Mesa-Treiber gibt.

Das soll dann geändert werden, wenn amdgpu dem herkömmlichen Mesa-Treiber in allen Belangen überlegen ist (es kann ja bislang nur einen default Treiber im Kernel geben - was sich zukünftig mit GLVND ändern könnte).
Da unbedarfte User ansonsten plötzlich einen Rückschritt erleben würden, ist das auch irgendwie nachvollziehbar.

Nur bei Southern Islands (GCN 1.0) sieht die Zukunft (mit Vulkan) noch ungewiss aus, AMD ist wie gesagt am überlegen, was da am schlauesten wäre, und hofft auch auf Mithilfe der Community, es ist also auch da mitnichten hoffnungslos.
Finde ich auch als haupsächlicher Nvidia-Nutzer gut so :smile:

[iuno]

amdgpu ist keine Alternative fuer mesa (radeonsi), sondern fuer radeon!

Ich glaube ich sollte mal eine Uebersicht machen...

[Achill]

Man hat eine Übersicht bei der X.org Foundation: RadeonFeature (http://xorg.freedesktop.org/wiki/RadeonFeature)

Diese ist zwar nicht besonder schon, glieder sich in 2D und 3D sowie Other, bennent den Treiber der dafür zuständig ist und welche features unterstützt werden.

Ein guter Wikiartikel der vielen Begriffe run um Linux und 2D/3D klärt: Free and open-source graphics device driver (https://en.wikipedia.org/wiki/Free_and_open-source_graphics_device_driver). Von dort stammt auch folgendes Bild:

https://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Linux_AMD_graphics_stack.svg/1280px-Linux_AMD_graphics_stack.svg.png?1453367409925

[iuno]

Ja, das Bild ist doch gut, dadurch sollte es klar werden.

Weisst du, woher die Info kommt, die Vulkan- und OpenCL Implementierungen wuerden im Maerz in Mesa aufgenommen?
Ich halte das aktuell fuer ein Geruecht, dazu ist mir bisher nichts bekannt. AMD hat angekuendigt, dass sie die Projekte zunaechst auch selbst pflegen wollen. iirc soll auch Gallium Compute die offizielle OpenCL-Implementierung bleiben, nicht die von AMD.
Dazu werden auch keine Quellen angegeben, noch steht im Artikel selbst irgendwas davon.

[Achill]

Ja, das Bild ist doch gut, dadurch sollte es klar werden.

Weisst du, woher die Info kommt, die Vulkan- und OpenCL Implementierungen wuerden im Maerz in Mesa aufgenommen?
Ich halte das aktuell fuer ein Geruecht, dazu ist mir bisher nichts bekannt. AMD hat angekuendigt, dass sie die Projekte zunaechst auch selbst pflegen wollen. iirc soll auch Gallium Compute die offizielle OpenCL-Implementierung bleiben, nicht die von AMD.
Dazu werden auch keine Quellen angegeben, noch steht im Artikel selbst irgendwas davon.

Das Bild stamm laut Legende vom 20 January 2015 - wird also Veraltet sein was die Information bzgl. geplanter Termine angeht - bis jetzt ist Vulkan ja noch nicht einmal draußen. :wink:

Aus der Präsentation AMD / LINUX DRIVER STACK / Sep. 2015 (http://wiki.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf), dort die 5. Folie, davon kann man es ableiten - nur kein Datum.

Edit:
- Die Folien 11 & 12 machen es dann nochmal explizit bzgl. OpenCL & Vulkan.
- Der März 2016 wahr ggf. ein Wunsch vom Ersteller der Grafik, damit würde Chance bestehen, dass es offiziell (ohne Backports / custom Repos) in den Versionen der Distributionen mit Releases-Datum im 3/4Q 2016 wäre.

[iuno]

Aus der Präsentation AMD / LINUX DRIVER STACK / Sep. 2015 (http://wiki.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf), dort die 5. Folie, davon kann man es ableiten - nur kein Datum.

Edit:
- Die Folien 11 & 12 machen es dann nochmal explizit bzgl. OpenCL & Vulkan.
Was kann man deiner Meinung nach ableiten? Ja, die Praesentation hatte ich auch im Kopf. Habe damals auch das Video dazu angeschaut und Alex Deucher hat iirc klar gesagt, dass es ein eigenes Projekt wird, das sie selbst maintainen. Dass es irgendwie zeitnah in Mesa aufgenommen werden soll, kann ich da beim besten Willen nicht hineininterpretieren.


John Carmack ist uebrigens begeistert von Vulkan...
https://twitter.com/ID_AA_Carmack/status/689248999845437441
...allerdings offenbar hauptsaechlich an Android interessiert :rolleyes:

[Kartenlehrling]

http://blogs.nvidia.com/blog/2016/01/19/vulkan-developers-day/
Vulkan Developers Day Draws Top Talent to NVIDIA’s Silicon Valley Campus

Die Sitzungen wurden aufgezeichnet, darf aber nicht öffentlicht werden bis zur offizielle Veröffentlichung von Vulkan.

Na ... Klasse!!

[Troyan]

Irgendwie sind die Leute mehr über Vulkan begeistert als über DX12. Und dabei hatte DX12 fast ein Jahr Vorsprung. Vielleicht hat Khronos doch noch die Kurve bekommen.

[SaschaW]

http://blogs.nvidia.com/blog/2016/01/19/vulkan-developers-day/
Vulkan Developers Day Draws Top Talent to NVIDIA’s Silicon Valley Campus



Na ... Klasse!!

Nicht mehr lange ;)


Irgendwie sind die Leute mehr über Vulkan begeistert als über DX12. Und dabei hatte DX12 fast ein Jahr Vorsprung. Vielleicht hat Khronos doch noch die Kurve bekommen.

DX 12 = Windows 10
Vulkan = Windows (bis runter auf XP), Linux, Android, etc.

Vermutlich liegt es daran. Da sich die Konzepte stark ähneln macht es kaum Sinn sich auf eine API zu stürzen die eigentlich nur von einer Platform unterstützt wird.

Und ja, Khronos hat hat die Kurve bekommen. Vulkan ist richtig gut geworden. Eigentlich wollte ich ja auch nach Vulkan noch weiter mit OpenGL werkeln, aber die API gefällt mir so gut dass ich OpenGL nicht mehr vermisse und vermutlich auch nix mehr damit machen werde.

[Blediator16]

Wie sieht es mit der Umgewöhnung aus?

[dargo]

Irgendwie sind die Leute mehr über Vulkan begeistert als über DX12.
Den Eindruck gewinne ich langsam auch. :freak: Mir solls recht sein. Egal ob DX12 oder Vulkan, Hauptsache DX11 wird so schnell wie möglich begraben.

[SaschaW]

Kommt drauf an wo man herkommt. Wenn man modernes OpenGL macht, also Uniform Block Objekte, Sampler und nix mehr mit der FFP dann gehts eigentlich. Wenn man DX12 oder Mantle macht dann dürfte es ganz einfach werden.

Ich hab zwar (als Hobbyist) relativ lang gebraucht, aber als ich damit anfangen durfte gabs weder fertige Speces, Docs oder ne umfangreiche Sammlung an Beispielen. Da war halt ganz viel guesswork inkl. Trial and Error. Und mit frühen Treibern ist das auch so ne Sache. Da ist man sich oft nicht sicher ob der Fehler auf der eigenen Seite liegt, an der noch nicht fertigen API oder an einem Fehler im Treiber ;)

Aber wenn Vulkan bald auf die Öffentlichkeit losgelassen wird sieht das anders aus. Es wird ein ordentliches SDK mit grundlegenden Beispielen geben, ordentliche Doku, ne Platform (via LunarG) und außer mir sind noch andere Leute mit an Bord die Beispiele direkt bzw. zeitnah zum Launch zur Verfügung stellen werden.

Wenn aber erstmal die Konzepte inne hat erscheint alles logisch und schlüssig. Klar ist es mehr Aufwand und man kann viel mehr falsch machen, aber es ist halt eine explizite API. D.h. man bekommt viel mehr Kontrolle und hat v.a. gegenüber OpenGL endlich wieder das Gefühl direkt an der Hardware zu programmieren. Bei OpenGL kann einem aufgrund der riesigen Statemachine ja keiner mehr so wirklich sagen wann was wo passiert xD

[iuno]

Irgendwie sind die Leute mehr über Vulkan begeistert als über DX12. Und dabei hatte DX12 fast ein Jahr Vorsprung.
Zu Recht :tongue:

[Widerwillig]

The Talos Principle wird Vulkan Unterstützung erhalten, sobald Vulkan offiziell draußen ist. Serious Sam 4 wird auch Vulkan unterstützen und Teil 3 wahrscheinlich auch:
https://www.gamingonlinux.com/articles/talos-principle-serious-sam-3-getting-vulkan-updates-serious-sam-4-will-be-on-a-much-improved-engine.6558

[Locuza]

Nvidia Blog: Vulkan Shader Resource Binding
https://developer.nvidia.com/vulkan-shader-resource-binding

Dazu ein paar interessante Kommentare von Andrew Lauritzen (Intel):

Does it it really work differently that the Mantle Shader Ressource Binding ? ( DescriptorSet, pipelinelayout, dynamic memory view etc ) https://www.amd.com/Documents/Mantle-Programming-Guide-and-API-Reference.pdf ( page 86 for ressource binding, page 105 for descriptorSets, 106 for dynamic view and etc )

Yes, it's actually quite different than Mantle despite similar naming - probably one of the API areas that was modified the most (the other being the render pass stuff).

Was that because it has to support a wide variety of hardware?
Mostly, yes - both in terms of efficiently supporting a broader range of hardware but also in terms of exposing functionality on other architectures such as push constants. There were other considerations as well (future expand-ability to bindless, DX design, etc).
Have you worked with Vulkan yet? If so I was wondering if you like it and if you think they're taking it in a good direction as far as future proofing goes?
A little bit but mostly just in the spec phase a while ago - I haven't done my hands-on with it yet on real drivers.

Direction is reasonable overall. I like the binding model stuff in DX12 slightly more but it makes sense why they couldn't go quite as far in Vulkan and what's there is certainly just fine.

https://forum.beyond3d.com/posts/1893382/

[AintCoolName]

Vulkan = Windows (bis runter auf XP), Linux, Android, etc.


Theoretisch, oder wer schreibt die Vulkan Treiber für XP? Wenn die von AMD/Nvidia kommen werden die unter Win7 nix mehr supporten. Oder könnten auch andere ein Vulkan Treiber für XP schreiben?

[iuno]

Koennte theoretisch schon, siehe noveau etc., machen wird das aber sicher keiner, einfach weil es keinen Bedarf gibt und es sinnlos ist.

[SaschaW]

Da es einen ICD-Loader gibt könnte rein theoretisch jeder einen eigenen ICD für Vulkan schreiben. Ich gehe auch davon aus das es für Betriebssysteme die nicht von Haus aus unterstützt werden ICDs von 3rd Party Anbietern geben wird der dort dann einfach nur einen Thin-Layer auf eine andere API mitbringt.

Zu XP kann ich nix sagen, da NDA. Und sinnlos ist der Support nicht unbedingt, siehe z.B. China. Da gabs mal ne interessante Statistik dass da moderne GPUs genutzt werden aber die fast alle unter XP laufen (ich vermute alle mit der selben Serial xD).

Aber klar, die IHVs werden erstmal aktuelle Betriebssysteme unterstützen.

[S940]

Zu XP kann ich nix sagen, da NDA. Und sinnlos ist der Support nicht unbedingt, siehe z.B. China. Da gabs mal ne interessante Statistik dass da moderne GPUs genutzt werden aber die fast alle unter XP laufen (ich vermute alle mit der selben Serial xD).
Naja, aber wenns ein brauchbares Vulkan unter Linux gibt, dann sollten die Asiaten doch schnell auf ein Linux umsteigen können ;)
Red Flag gibts zwar nicht mehr, aber es wird sich schon was Passendes finden ;)

[iuno]

Und wenn in China ein Sack Reis umfaellt wird XP imho trotzdem nicht wichtiger.
In welchem Anwendungsgebiet soll man da noch Vulkan brauchen wo es OpenGL nicht tut? Das waeren imho voellig verschwendete Ressourcen

[SaschaW]

Am 18.Febraur gibts das erste öffentliche Webinar zu Vulkan : https://www.khronos.org/news/events/vulkan-webinar

Wir sind auf der Zielgeraden :)

[Kartenlehrling]

zwei Wochen können soo lang sein.

[SaschaW]

Kommt stark drauf an. Wenn der Quellcode noch etwas Feinschliff braucht sind zwei Wochen doch sehr wenig. Vor allem wenn man meint man müsste jetzt noch was komplett Neues bauen xD

[iuno]

Vor allem wenn man meint man müsste jetzt noch was komplett Neues bauen
Hoer auf zu teasen ;D was soll denn noch komplett Neues kommen?

OT: wieder ein unterirdischer Port, es wird Zeit! http://www.heise.de/ct/artikel/Strategie-Hit-XCOM-2-Port-ist-Mord-3098163.html

[Kartenlehrling]

Dabei zeigte sich: Unter Linux läuft XCOM 2 wesentlich langsamer als unter Windows.
So erzeugt die GeForce GTX 970 in Full HD und niedriger Detailstufe nur 46 fps (Windows: 84 fps), bei "hoch" nur 30 fps.
Die Radeon R9 380X packt selbst in der niedrigsten Detailstufe wesentlich weniger als 30 fps (Windows: 75 fps).
Zudem bricht die Bildrate im Unterschied zur Windows-Version manchmal kurz, aber heftig ein – so macht Spielen keinen Spaß.


joo das klingt nicht gut, aber vor dem 18.02 werden wir sowieso nichts sehen.
Ich habe gestern geschaut was es an Benchmarks gibt und selbst die werden wohl erst in 2 Wochen frei gegeben.


http://www.basemark.com/2015/11/10/basemark-extends-its-benchmarking-lead-with-a-vulkan-performance-test/
Basemark®

https://gfxbench.com/news_single.jsp?id=26889751
Kishonti demos GFXBench 5 Beta at SIGGRAPH 2015

[SaschaW]

Hoer auf zu teasen ;D was soll denn noch komplett Neues kommen?

Das Bezug sich auf mich, nicht Vulkan ;)

[iuno]

joo das klingt nicht gut, aber vor dem 18.02 werden wir sowieso nichts sehen.
Ich habe gestern geschaut was es an Benchmarks gibt und selbst die werden wohl erst in 2 Wochen frei gegeben.


http://www.basemark.com/2015/11/10/basemark-extends-its-benchmarking-lead-with-a-vulkan-performance-test/
Basemark®

https://gfxbench.com/news_single.jsp?id=26889751
Kishonti demos GFXBench 5 Beta at SIGGRAPH 2015
Woher nimmst du das Datum? Basemark sagt Q2, GFXBench gar nichts :confused:

@SaschaW: oh, dann war das wohl ein Missverstaendnis
Also hast du was gebaut, was du am day 1 veroeffentlichen willst? :D

[SaschaW]

Ja, von mir gibts auch ein paar Sachen zum Launch. U.a. eine Vulkan Hardware Datenbank (siehe http://www.gpuinfo.org/) und vermutlich ein paar Quellcodebeispiele zur Nutzung von Vulkan (Windows, Linux, Android).

[iuno]

ja, die db habe ich schon gesehen.
cool. wie bist du eigentlich damals 'reingekommen'? So wie ich das sehe, machst du das ja 'nur' aus Interesse/als Hobby oder?

[SaschaW]

Ja, ich mach das nur als Hobby. Aber als man das Advisory Panel aufgebaut hat wollte man einen möglichst breiten Schnitt durch die "Industrie" hinweg, also IHVs, ISVs, Spielebranche, Industrie, etc. um Feedback aus allen Richtungen zu bekommen.

Und ich bin dann u.a. wegen der Hardwaredatenbanken gefragt worden, und weil ich als Hobbyist schneller und gezielter Feedback geben kann. Während z.B. ein Engine-Entwickler nur schwer losgelöste Testfälle zur Verfügung stellen kann ist das bei jemandem wie mir ganz anders. Wenn ich feststelle dass bei einer bestimmten Technik (z.B. nem Tessellationshader) etwas nicht stimmt kann ich z.B. einem IHV direkt nen Testfall zur Verfügung stellen und dann geht das mit der Feedbackschleife ganz einfach.

Deshalb sind dann auch Leute wie ich mit dabei, und ich hoffe dass ich meinen Teil dazu beitragen konnte das der Vulkan-Launch gut verläuft :)

P.S. : Am 8. April gibts in München eine Veranstaltung des Khronos Chapters rund um Vulkan (http://www.meetup.com/de-DE/Khronos-Munchen-Chapter/events/228749377/). Wenn nichts dazwischen kommt werde ich auch da sein und meinen Vulkan Kram zeigen. Wer also Interesse hat, noch sind Plätze frei (findet bei AMD statt).

[Troyan]

nVidia hat weitere Artikel zu Vulkan und OpenGL online gestellt:
https://developer.nvidia.com/opengl-vulkan
https://developer.nvidia.com/transitioning-opengl-vulkan

https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/Vulkan_gltransition/vulkan_gltransition_maintenance2.png

Das veranschaulicht deutlich, wieso eine Low-Level API als "fix" für schlechte OpenGl und/oder DX11 Treiber keine Alternative ist.


Vulkan being so low-level means that getting the best out of different hardware architectures will very likely require dedicated code-paths. This is fundamentally not that different to the reality of using extensions in OpenGL, but a reminder that Vulkan doesn’t magically do away with it. It provides a much higher base-level in terms of capabilities, and a concise set of function entry points, but differences in the hardware capabilities and preferred operations will still manifest themselves.

[-/\-CruNcher-/\-]

Natürlich ist es kein allheilmittel hand optimierung mit Brain und Wissen wird es nicht ersetzen es ist eben ein tool um mehr ruaszuhauen für jemanden der das Wissen über die Hardware hat dieses wissen haben vor allem die IHV Engineers selber aber nur sehr wenige Entwickler und auch nur die die sich wirklich mit Reverse Engineering auseinandersetzen vor allem bei Nvidia hat man sehr wenig Daten zur Verfügung und muss Learning by doing aber weiss nie was eigentlich irgendwo wirklich passiert und wieso, es ist da sehr viel Try and Error und Erfahrung im Spiel das wird sich mit DX 12 und Vulkan auch nicht extreme verändern zumal Entwickler nicht alles wissen sollen, nur das nötigste was man sie wissen lässt ;)

[SaschaW]

vor allem bei Nvidia hat man sehr wenig Daten zur Verfügung und muss Learning by doing aber weiss nie was eigentlich irgendwo wirklich passiert und wieso, es ist da sehr viel Try and Error und Erfahrung im Spiel das wird sich mit DX 12 und Vulkan auch nicht extreme verändern zumal Entwickler nicht alles wissen sollen, nur das nötigste was man sie wissen lässt ;)

Dem muss ich komplett wiedersprechen. Grade mit Vulkan (und mit DX12 sicherlich auch) hat man aufgrund der expliziten Natur der API eine ziemlich direkte Kontrolle über das was die GPU macht, und v.a. auch wann sie das macht. Auch inkl. GPU-Timestamps und Pipeline Performancecounter.

[d2kx]

http://www.ozone3d.net/public/jegx/201502/opengl-next-vulkan.jpg

[Lurtz]

Macht mal hin statt rumzuteasern, ich hätte mal wieder Lust auf Talos Principle ;) :)


https://steamdb.info/app/257510/depots/?branch=ihvbeta
Könnte der Betabranch für Vulkan sein?

[dargo]

http://www.ozone3d.net/public/jegx/201502/opengl-next-vulkan.jpg
Du machst es spannend. :D

[SaschaW]

Wenn man im Netz sucht und den richtigen Leuten auf Twitter folgt bekommt man jetzt schon raus wann Release ist ;)

In der Zwischenzeit schaue ich auf welcher Hardware/OS-Kombi mein Vulkan Kram läuft, und mach die readme Markdowns fertig...

[Achill]

Am Do. (18.02.) ist ja das Webinar (https://twitter.com/ahcox/status/697880828123222017) von LunarG zum Vulkan-SDK. Ich kenne das aus der Java/Konfernz-Welt so, dass man eigentlich den SW-Stack spätestes zum Zeitpunkt des Webinars hat - viele Coden teile des Webinars gleich mit.

=> Vermutung: Wird also etwas zwischen Jetzt und 18.02. 9AM PT sein ...

Die Frage ist noch, warum Andrew Cox heute sein Vulkan-Shirt (https://twitter.com/1ace/status/699513909531799552) trägt und schreibt: "Obviously had to wear that shirt today" ... ;D

[kruemelmonster]

AIDA64 wird nach der Veröffentlichung von Vulkan ein passendes Update bekommen:

We will definitely implement a new page to show Vulkan video adapter information. We just need to wait for the first official Vulkan-ready drivers to be rolled out by both AMD and nVIDIA. We may also phase out the existing Mantle page at one point. But for legacy systems it makes sense to keep it for a while.

[SaschaW]

AIDA64 wird nach der Veröffentlichung von Vulkan ein passendes Update bekommen:

Unter http://vulkan.gpuinfo.org/ werde ich eine Vulkan Hardware Datenbank zur Verfügung stellen, inkl. Clientanwendungen für Windows, Linux (beide vorerst nur x64) und Android.

Wie bei meinen OpenGL-Datenbanken gibts hier dann detaillierte Hardwarereports mit allen Infos die Vulkan her gibt (mehr als OpenGL ;) ), und man kann die Reports dann auch vergleichen.

Anders als bei OpenGL und OpenGL ES wird man hier also endlich auch Dekstop und Mobile GPUs vergleichen können :)

Wenn alles passt kommt die Datenbank kurz nach dem Launch.

[SaschaW]

Es ist da : https://www.khronos.org/vulkan/

Mein Kram geht auch gleich online :)

[d2kx]

Vulkan 1.0 Released: What You Need To Know About This Cross-Platform, High-Performance Graphics API (http://www.phoronix.com/scan.php?page=article&item=vulkan-10&num=1)
Phoronix

Khronos Releases Vulkan 1.0 Specification (https://www.khronos.org/news/press/khronos-releases-vulkan-1-0-specification)
Khronos

Vulkan 1.0 Specification Released: Drivers & Games Inbound (http://www.anandtech.com/show/10035/vulkan-10-released)
Anandtech

[Screemer]

oha. dachte 22.2. wäre termin.

und keine amd treiber für linux?! wieder mal ein gefundenes fressen für die hater.

[iuno]

Kein launch Treiber von AMD... :facepalm:

[Troyan]

Es ist da : https://www.khronos.org/vulkan/

Mein Kram geht auch gleich online :)

Stehst du unter NDA, wenn es um nVidia und AMD geht? :confused:
Ansonsten wären Einblicke im Support von beiden sehr interessant.

[SaschaW]

Omfg, so nervös und froh gleichzeitig war ich noch nie. Lade grade meinen Kram hoch.

Alleine das mein Name auf der Vulkan Launch Page neben NVIDIA, AMD und Co. steht find ich grad voll geil xD

[SaschaW]

Kein launch Treiber von AMD... :facepalm:

Doch : http://support.amd.com/en-us/kb-articles/Pages/Radeon-Vulkan-Beta.aspx

[SaschaW]

Stehst du unter NDA, wenn es um nVidia und AMD geht? :confused:
Ansonsten wären Einblicke im Support von beiden sehr interessant.

Ja, ich hab ne handvoll NDAs unterschrieben, dazu kann ich also eigentlich nix sagen.

[iuno]

Doch : http://support.amd.com/en-us/kb-articles/Pages/Radeon-Vulkan-Beta.aspx

Ja, fuer Windows...
vielleicht ist durch den groessen umbau zu entschuldigen, solange es noch nicht "akut" wird, schoen ist das aber nicht!

[SaschaW]

Linux!
Ah sorry, ganz übersehen. Natürlich schade, aber wird sicherlich nicht lange dauern bis der kommt. ;)

[iuno]

Alleine dass mein Name auf der Vulkan Launch Page neben NVIDIA, AMD und Co. steht find ich grad voll geil xD
Sieht schon gut aus, als einer von zwei "privaten" dort zu stehen herzlichen Glueckwunsch :D

https://moltengl.com/metalvk/
Heisst hoffentlich nicht, dass Apple ueberhaupt kein Interesse zeigt, irgendwann mal auf Vulkan zu setzen...

[Troyan]

Du bist sogar auf der nVidia developer Seite mit Zitat aufgeführt. :D

[M4xw0lf]

The Talos Principle soll es auf Steam jetzt mit Vulkan geben, als beta?
(links unten)
http://images.anandtech.com/galleries/4718/Khronos%20Vulkan%20Launch%20Press%20Briefing%20Feb16%20nt1-page-013_575px.jpg

[Locuza]

https://moltengl.com/metalvk/
Heisst hoffentlich nicht, dass Apple ueberhaupt kein Interesse zeigt, irgendwann mal auf Vulkan zu setzen...
Fucking awesome!??
Das ist doch praktisch Vulkan Support, nur intern anders verpackt?

[dildo4u]

Nvidia's Vulkan Treiber.

https://developer.nvidia.com/vulkan-driver

[iuno]

Fucking awesome!??
Das ist doch praktisch Vulkan Support, nur intern anders verpackt?
Ja, ist es, aber es haengt eben doch noch eine weitere Schicht dazwischen. Klar, ist das fuer den Anfang super, aber noch besser waere eben die Unterstuetzung von Apple selbst. Erweiterte Debugging Features koennten sie ja als eigene Extensions beibehalten.
Zudem ist der Kram halt wieder proprietaer und kostet Lizenzgebuehren. Fuer kleinere Entwickler kann das durchaus ein Faktor sein.

[Lurtz]

The Talos Principle soll es auf Steam jetzt mit Vulkan geben, als beta?
(links unten)
http://images.anandtech.com/galleries/4718/Khronos%20Vulkan%20Launch%20Press%20Briefing%20Feb16%20nt1-page-013_575px.jpg
Also eine passwortlose Beta gibts noch nicht dafür bei Steam. Weiß jemand mehr?