Vulkan Grafik-API

[Locuza]

Puh, leider ist mein Kopf kurzzeitig abgehoben.
Ich dachte MetalVK kommt von Apple selber und nicht einer Third-Party. :redface:

[d2kx]

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

Vulkan ist Liebe :love:

Zur Treibersituation wird es in den nächsten Tagen noch ein paar mehr Infos geben.

[M4xw0lf]

Pah, Treibersituation, ich will Spielebenchmarks! :freak:

[Lord_X]

Also eine passwortlose Beta gibts noch nicht dafür bei Steam. Weiß jemand mehr?
Cool bleiben:

The delay was on getting conformant drivers in hand. The conformant Vulkan 1.0 drivers are really coming about at last-minute that the Windows version should now be available on Steam in beta form.

[iuno]

Also eine passwortlose Beta gibts noch nicht dafür bei Steam. Weiß jemand mehr?
Sollte heute kommen (nur Windows), Geduld ;)

Pah, Treibersituation, ich will Spielebenchmarks! :freak:
Von welchem Spiel genau und was erhoffst du dir davon :freak:
Es wird uebrigens auch nicht von heute auf morgen alles besser werden. DirectX12 ist seit einem halben Jahr draussen und da hat sich auch noch nichts bewegt

[Timbaloo]

Pah, Treibersituation, ich will Spielebenchmarks! :freak:
Eben, das spannende kommt ja jetzt erst: Die Adaptionsrate und der tatsächliche Vorteil in realen Implementierungen.

[d2kx]

qZLzz3OOl3A

Radeon GPUs are ready for the Vulkan graphics API (https://community.amd.com/community/gaming/blog/2016/02/16/radeon-gpus-are-ready-for-the-vulkan-graphics-api)

[aufkrawall]

Für Talos Principle bei Steam Beta einstellen, dann kann man im Menü Vulkan auswählen.

[M4xw0lf]

Für Talos Principle bei Steam Beta einstellen, dann kann man im Menü Vulkan auswählen.
Wuhuu!

[aufkrawall]

Wuhuu!
Yahaaa! :D
http://abload.de/img/crash2zumw.png (http://abload.de/image.php?img=crash2zumw.png)

:freak:

[Lurtz]

Beta für Talos Principle ist jetzt online:
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/

[SaschaW]

Android Image (6.0) mit Vulkan Support für NVIDIAs Shield TV ist jetzt wohl auch öffentlich verfügbar.

[M4xw0lf]

Yahaaa! :D
http://abload.de/img/crash2zumw.png (http://abload.de/image.php?img=crash2zumw.png)

:freak:
Uncoohool!

[Kartenlehrling]

Beta für Talos Principle ist jetzt online:
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/

Dann mal los und gleich in 1600x900 Ultra testen DX11 und Vulkan,
damit sollte man im CPU-Limit hängen unter DX11.

[kruemelmonster]

You will need any one of the following Kepler or Maxwell (both first and second generation Maxwell) based GPUs to get access to Vulkan functionality

So although Fermi is still slated to get DirectX 12 support (and this is something we’re looking into separately), only GPUs starting with Kepler will get Vulkan.

Schade, ich dachte Fermi wäre angesichts von OpenGL 4.5 und dem kommenden DX12 Support auch Vulkan-fähig.

/edit: NVIDIA Vulkan Chopper Demo: https://nvidia.app.box.com/s/rj9nzxkpz21qu34h8zew301kray9urbf
/edit2: Thank you. We're already working on it

[aufkrawall]

Dann mal los und gleich in 1600x900 Ultra testen DX11 und Vulkan,
damit sollte man im CPU-Limit hängen unter DX11.
Man kann gar nix benchen, zumindest nicht mit dem NV-Vulkantreiber. Der hat nämlich eine echt miese Performance mit DX11 bei Talos.
Vulkan scheint bei Talos auch noch ziemlich bescheiden zu laufen, zumindest hier mit der 980.

Edit: Aha, oder auch nicht. Der Treiber ist teilweise hängen geblieben, die GPU taktet nicht mehr hoch.

[Locuza]

Schade, ich dachte Fermi wäre angesichts von OpenGL 4.5 und dem kommenden DX12 Support auch Vulkan-fähig.

Ich meine mich zu erinnern, dass Vulkan Support für Fermi auch geplant war.
DX12 ist für Fermi auch noch nicht fertig.
Entweder das kommt noch oder Nvidia hat die alten Pläne begraben.

[iuno]

Schade, ich dachte Fermi wäre angesichts von OpenGL 4.5 und dem kommenden DX12 Support auch Vulkan-fähig.
Waere sie auch, wollte Nvidia einen Treiber veroeffentlichen.

@aufkrawall: naja, passiert... der Nvidia Treiber ist ja auch erst beta oder?!

[Achill]

http://i.imgur.com/WBpMvLa.jpg

[iuno]

@Achill: das Bild ist schon "alt" :P oder kommt das jetzt ingame, wenn man die Vulkan Version startet?

[aufkrawall]

@aufkrawall: naja, passiert... der Nvidia Treiber ist ja auch erst beta oder?!
Klar, ich beschwer mich ja auch nicht. Nach einem Neustart gab es dann soweit hier bislang keine Crashes mehr.
Es sind hier in WQHD 63fps mit Vulkan vs. 108fps mit DX11 an der selben Stelle.
Da geht bestimmt noch mehr, immerhin konnte ich noch keine Grafikfehler sehen.

Edit: Ach so, mit Vulkan läuft das Spiel übrigens nur im borderless oder windowed Modus, mit 60Hz gäbe es also bei 60fps einen Cap. Ich hab allerdings 75Hz.
Edit 2: Es gäbe wohl doch keinen Cap.

[Locuza]

Ein Neogaf Mitglied hat eine ähnliche Erfahrung gesammelt:
Tested The Talos Principle with 356.39 vulkan drivers - its definitely runs slower than dx11 (can't keep 60 fps all the time) and stutters like mad.
http://www.neogaf.com/forum/showpost.php?p=195476825&postcount=75

[iuno]

Netter Kurswechsel von Intel uebrigens, jetzt wo deren IGPs mal in brauchbare Regionen vordringen.
However, from another source I heard there was indications Intel is pursuing both an open and closed-source Linux Vulkan driver.
Nachdem sie jetzt auch firmware blobs haben wird der Vulkan Treiber unter Verschluss gehalten. Wenn das stimmt, kann ich mir vorstellen, dass LunarG den early prototype Kram freigibt und Intel den rest dann der Community ueberlaesst. Vielen Dank auch

Kommando zurueck: https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware
Klingt nicht danach, als waere die Info von Michael valide. Aber abwarten ;)


Die Talos beta soll auf Linux in 1-2 Tagen mit Vulkan laufen: https://steamcommunity.com/app/257510/discussions/0/412447331651559970/#c412447331651682425

[Lurtz]

Hier @AMD läuft Talos mit DX11 auch merklich smoother.

[SaschaW]

Netter Kurswechsel von Intel uebrigens, jetzt wo deren IGPs mal in brauchbare Regionen vordringen.

Nachdem sie jetzt auch firmware blobs haben wird der Vulkan Treiber unter Verschluss gehalten. Wenn das stimmt, kann ich mir vorstellen, dass LunarG den early prototype Kram freigibt und Intel den rest dann der Community ueberlaesst. Vielen Dank auch

Kommando zurueck: https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware
Klingt nicht danach, als waere die Info von Michael valide. Aber abwarten ;)

Den Beispiel-ICD für Intel aus dem LunarG-SDK gibts hier : https://github.com/LunarG/VulkanTools/tree/master/icd

Hab mir den jetzt aktuell nicht mehr angeschaut (war schon genug Arbeit dauernd GPUs zu wechseln xD), aber das ist zumindest mal ein Anfang. Auch wenn dem Treiber ganz viele Features fehlen und nur ein paar grundlegende Sachen gehen. Aber ist ja alles open source :)

[Loeschzwerg]

Beta für Talos Principle ist jetzt online:
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/

39.99€ :( Ist mir für einen kurzen Test mit meiner Nano zu viel. Oder lohnt das Spiel?

[Lurtz]

39.99€ :( Ist mir für einen kurzen Test mit meiner Nano zu viel. Oder lohnt das Spiel?
Das Spiel lohnt sich sehr, war aber schon deutlich günstiger zu haben...

[iuno]

Ist glaube ich in jedem Sale, erst letzte Woche wieder fuer 10€ iirc.

[Loeschzwerg]

Ok, dann warte ich. Für nen 10er bin ich dabei.

[Demirug]

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

Irgendwann vielleicht mal. Aber derzeit fährt Apple eine Strategie die das portieren von iOS auf was anderes als MacOS X so schwer wie möglich macht.

[iuno]

Irgendwann vielleicht mal. Aber derzeit fährt Apple eine Strategie die das portieren von iOS auf was anderes als MacOS X so schwer wie möglich macht.
Naja, die Portierung einer iOS App woanders hin macht auch nur bedingt Sinn, darum geht es hier aber auch gar nicht, ganz im Gegenteil. Es geht darum, Apps AUF die Plattform zu bekommen.
Es ist ja nun nicht so, dass iOS/OSX die #1 sind, was Spiele betrifft

[SaschaW]

Irgendwann vielleicht mal. Aber derzeit fährt Apple eine Strategie die das portieren von iOS auf was anderes als MacOS X so schwer wie möglich macht.

Apple ist ja Promoter (https://www.khronos.org/members/promoters) Mitglied bei Khronos, von daher kann man also hoffen.

Aber ja, die grundsätzliche Einstellung, besonders in Richtung Entwicklung, nur eigenen Kram nutzen zu wollen wird man nicht so einfach ablegen.

V.a. nicht wenn man ja grade erst MetaL eingeführt hat.

Schön wärs natürlich, denn MetalVK ist ja auch nur ein (sehr dünner) Layer der dann trotzdem zumindest ein wenig Overhead mitbringt.

Aber aus Entwicklersicht sehr interessant, denn mit MetalVK kann man den gleichen Rendercode dann für Windows, Linux, Mac, iOS und Android verwenden. Bin mal gespannt wie Brennwill die WSI umsetzen.

[Achill]

W4dWzIagMPM

Für eine ARM + Mali GPU schon beeindruckend. Leider keine Details was genau zum Einsatz kam.

[kruemelmonster]

39.99€ :( Ist mir für einen kurzen Test mit meiner Nano zu viel. Oder lohnt das Spiel?

Die Demo auf Steam reicht für einen Test aus, mit der 64bit Beta Build und dem 356.39 steht Vulkan als API zur Auswahl. Läuft auf meiner GTX 670 ebenfalls bescheidener als DX11 und stürzt auch noch gerne ab, zeigt aber wie bei aufkrawall keinerlei Grafikfehler.

[Nightspider]

http://youtu.be/W4dWzIagMPM

Für eine ARM + Mali GPU schon beeindruckend. Leider keine Details was genau zum Einsatz kam.


Naja wenn man sich überlegt das aktuelle highend SoCs die Leistung der PS360 haben dann beeindruckt das Video imo nur mäßig.

[Demirug]

Naja, die Portierung einer iOS App woanders hin macht auch nur bedingt Sinn, darum geht es hier aber auch gar nicht, ganz im Gegenteil. Es geht darum, Apps AUF die Plattform zu bekommen.
Es ist ja nun nicht so, dass iOS/OSX die #1 sind, was Spiele betrifft

Du hast noch nicht mit Apple zugearbeitet oder?

Apple ist es schlicht und ergreifend egal ob das portieren auf ihre Plattformen aufwendig ist oder nicht. Wenn du auf ihren Plattformen Geld verdienen willst ist es dein Problem wie du deine Sachen zum laufen bekommst.

Apple ist ja Promoter (https://www.khronos.org/members/promoters) Mitglied bei Khronos, von daher kann man also hoffen.

Aber ja, die grundsätzliche Einstellung, besonders in Richtung Entwicklung, nur eigenen Kram nutzen zu wollen wird man nicht so einfach ablegen.

V.a. nicht wenn man ja grade erst MetaL eingeführt hat.

Schön wärs natürlich, denn MetalVK ist ja auch nur ein (sehr dünner) Layer der dann trotzdem zumindest ein wenig Overhead mitbringt.

Aber aus Entwicklersicht sehr interessant, denn mit MetalVK kann man den gleichen Rendercode dann für Windows, Linux, Mac, iOS und Android verwenden. Bin mal gespannt wie Brennwill die WSI umsetzen.

Da Metal weitaus weniger kann als Vulkan glaube ich nicht das man den gleichen Rendercode nutzen kann. Und für das was geht hat man den zusätzlichen Overhead für den Wrapper am Hals. Das ist dann eher was für Leute die nicht die Zeit und Manpower haben es richtig zu machen.

[LadyWhirlwind]

Apple ist ja Promoter (https://www.khronos.org/members/promoters) Mitglied bei Khronos, von daher kann man also hoffen.

Aber ja, die grundsätzliche Einstellung, besonders in Richtung Entwicklung, nur eigenen Kram nutzen zu wollen wird man nicht so einfach ablegen.

V.a. nicht wenn man ja grade erst MetaL eingeführt hat.

Schön wärs natürlich, denn MetalVK ist ja auch nur ein (sehr dünner) Layer der dann trotzdem zumindest ein wenig Overhead mitbringt.

Aber aus Entwicklersicht sehr interessant, denn mit MetalVK kann man den gleichen Rendercode dann für Windows, Linux, Mac, iOS und Android verwenden. Bin mal gespannt wie Brennwill die WSI umsetzen.


Eine Entscheidung auf Vulkan zu setzen seitesn Apple geht schon zeitlich nicht auf. Metal kam im Herbst 14 für iOS, d.h. Die Plannungen für Metal müssen schon 2013 angefangen haben. Zu diesem Zeitpunkt war Vulkan noch Zukunftsmusik. Mit etwas Mehr Verspätung hätte Apple Vulkan erest im 2017 für iOS bringen können, also 3 Jahre nach Metal. Metal auch auf OSX nachzuziehen ist da nur logisch. Eine andere Entscheidung wäre nur schwer zu rechtfertigen gewesen.

Das Apple bei Metal mehr und bessere Kontrolle über das Produkt hat, spricht auch nicht für Vulkan. Ich denke für Apple kommen nur ausgereifte Lösungen anstelle von eigenentwicklungen in Frage.

[kruemelmonster]

Ich meine mich zu erinnern, dass Vulkan Support für Fermi auch geplant war.
DX12 ist für Fermi auch noch nicht fertig.
Entweder das kommt noch oder Nvidia hat die alten Pläne begraben.

Laut PCPer liegts an NV bzw dem niedrigen Marktanteil der Fermis:

The [Vulkan] standard is compatible with Fermi GPUs, but NVIDIA does not plan on supporting the API for those users due to its low market share. That said, they are paying attention to user feedback and they are not ruling it out, which probably means that they are keeping an open mind in case some piece of software gets popular and depends upon Vulkan.

@Blaire: Bitte am Ball bleiben. :biggrin:

[Demirug]

http://youtu.be/W4dWzIagMPM

Für eine ARM + Mali GPU schon beeindruckend. Leider keine Details was genau zum Einsatz kam.

Mali T760 MP8 oder besser. Sie hatten vielleicht auch schon einen T880 MPx dafür.

Der T760 MP8 hat jedenfalls in etwa die Leistung eines Tegra K1.

Wenn ich den Blog post dazu richtig interpretiere ist hier gar nicht die GPU Leistung das Problem sondern die CPU. Das wiederum lässt mich glauben das man dort eine sehr große Anzahl von Objekten rendert. Deswegen die Kamera auch so das man die ganze Insel sieht.

[z3ck3]

Gibt es irgendwo Demos, Benchmarks etc., what ever? Ich kauf doch kein Spiel für 40 € um etwas auszuprobieren. :D

[aufkrawall]

Mein "Benchmark" steht ja oben:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10945067&postcount=521
Und laut Lurtz läuft es auch auf AMd mit DX11 besser.

[d2kx]

The Talos Principle - eigener Benchmark/Szene (Startgebiet)

AMD Radeon R9 390
2560x1440, all max, 4x MSAA

AMD 16.1.1-Feb12
DX11 - 91 FPS
OpenGL - 43 FPS

AMD Vulkan beta
Vulkan - 62 FPS
OpenGL - 55 FPS

[Loeschzwerg]

Die Demo auf Steam reicht für einen Test aus, mit der 64bit Beta Build und dem 356.39 steht Vulkan als API zur Auswahl. Läuft auf meiner GTX 670 ebenfalls bescheidener als DX11 und stürzt auch noch gerne ab, zeigt aber wie bei aufkrawall keinerlei Grafikfehler.

;( Bei mir fehlt Vulkan als Auswahl, obwohl sich die Demo mit "Public beta" meldet. Sonst muss ich nichts einstellen, oder?

Habe vom 16.1.1 Feb12 ein Update auf Vulkan Beta gemacht, evtl. hat sich hier etwas gefressen.

[aufkrawall]

64 Bit Version gestartet und Vulkan-Treiber installiert?
64 Bit muss man bei dem Spiel leider immer vor jedem Start über Steam als Launcher auswählen.

[Lord_X]

http://www.computerbase.de/2016-02/vulkan-erste-benchmarks-der-neuen-api-in-talos-principle/

http://fs5.directupload.net/images/160216/mpfbzrmx.png

...Zudem zeigt sich, dass entweder die Vulkan-Implementierung von Croteam AMD-GPUs derzeit besser schmeckt als den Nvidia-Pendants oder der AMD-Treiber bezüglich der API weiter fortgeschritten ist als der Nvidias. Auch läuft das Spiel selbst auf der AMD-Grafikkarte besser. Während diese (trotz hoher Frameraten) nur etwas stockt, ruckelt der Nvidia-Beschleuniger deutlich mehr...

[just4FunTA]

wow 30fps vulkan ist ja voll der hammer. must have now.;D:freak:

http://abload.de/img/ugqrsbi.jpg

[d2kx]

Oculus VR's Carmack Calls Khronos' Vulkan 'Impressive' (http://vrfocus.com/archives/29661/oculus-vrs-carmack-calls-khronos-vulkan-impressive/)

The Qt Company joins Khronos Group and promotes Vulkan (http://blog.qt.io/blog/2016/02/16/the-qt-company-joins-khronos-group-and-promotes-vulkan/)

[captain_drink]

...Zudem zeigt sich, dass entweder die Vulkan-Implementierung von Croteam AMD-GPUs derzeit besser schmeckt als den Nvidia-Pendants oder der AMD-Treiber bezüglich der API weiter fortgeschritten ist als der Nvidias.

Warum? Im CPU-Limit sind die Frames doch identisch.
Dass AMD im ansteigenden GPU-Limit überproportional hinzugewinnt (gerade Fiji), ist ja nichts Neues (und nicht ausschließlich auf sinkende CPU-Limits zurückzuführen).

[z3ck3]

Mein "Benchmark" steht ja oben:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10945067&postcount=521
Und laut Lurtz läuft es auch auf AMd mit DX11 besser.
Ich meinte eher eine Demo die man selbst ausprobieren kann. Optimalerweise mit Renderern für OpenGL, Vulcan, DirectX 11 (und 12) die auch wirklich optimiert wurden um einen direkten Vergleich zu ermöglichen.

Ich gehe mal davon aus das TTP ursprünglich für DirektX optimiert wurde. Die Einzige Aussage die ich aus den Diagrammen ableiten kann ist das Vulcan OpenGL ordentlich davon zieht. Nur in wie weit ist das ein Problem der Optimierung oder eben tatsächlich in der API begründet.

[Lurtz]

Entwickler über den Vulkan-Port für Talos:
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/?insideModal=1#c412447331651997070

[dargo]

http://www.computerbase.de/2016-02/vulkan-erste-benchmarks-der-neuen-api-in-talos-principle/

http://fs5.directupload.net/images/160216/mpfbzrmx.png

...Zudem zeigt sich, dass entweder die Vulkan-Implementierung von Croteam AMD-GPUs derzeit besser schmeckt als den Nvidia-Pendants oder der AMD-Treiber bezüglich der API weiter fortgeschritten ist als der Nvidias. Auch läuft das Spiel selbst auf der AMD-Grafikkarte besser. Während diese (trotz hoher Frameraten) nur etwas stockt, ruckelt der Nvidia-Beschleuniger deutlich mehr...
Gibt bei beiden IHVs noch einiges zu tun. Naja... war ja auch zu erwarten.

[Kartenlehrling]

Entwickler über den Vulkan-Port für Talos:
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/?insideModal=1#c412447331651997070

Heist das es immer noch Singlecore läuft?
Kann mal einer die CPU Auslastung bei einem 4/8core zeigen.?




http://www.hardwarepal.com/wp-content/uploads/2014/12/The-Talos-Principle-CPU-Usage.jpg

[SaschaW]

Hm, die Vulkan Beta von Talons Principle hat bei mir jetzt circa 20s ganz fies vor sich hingeruckelt und dann mein System komplett aufghängt. Das bekomm selbst ich mit meinem Demos nicht mehr hin, da sollte eigentlich die TDR von Windows reingrätschen.

Schade :(

[z3ck3]

Wenn ich das richtig verstehe ist diese Beta eher eine Pre Alpha. Man hat es bisher nur mal eben so fix hingebogen das es irgendwie läuft. So jedenfalls lese ich den Entwicklerkommentar.

[Lightning]

Wenn ich das richtig verstehe ist diese Beta eher eine Pre Alpha. Man hat es bisher nur mal eben so fix hingebogen das es irgendwie läuft. So jedenfalls lese ich den Entwicklerkommentar.

..dazu noch auf frühen Beta-Treibern. Und läuft trotzdem schon schneller als die OpenGL-Version. :freak:

Ich finde die Vulkan-Performance durchaus beeindruckend für den Anfang.

[Troyan]

Sieht gut für einen einfachen OpenGL-Port.

[Demirug]

Hm, die Vulkan Beta von Talons Principle hat bei mir jetzt circa 20s ganz fies vor sich hingeruckelt und dann mein System komplett aufghängt. Das bekomm selbst ich mit meinem Demos nicht mehr hin, da sollte eigentlich die TDR von Windows reingrätschen.

Schade :(

Das hängt davon ab wie man die GPU crasht (hatte damit auch schon meinen Spass). Es ist Möglich das die GPU gegenüber dem Treiber weiterhin fleißig behauptet das sie rendert aber man den Scanout Teil so zerschossen hat das er auf dem gleichen Bild hängen bleibt. In dem Fall merkt es die TDR nicht.

Wenn ich das richtig verstehe ist diese Beta eher eine Pre Alpha. Man hat es bisher nur mal eben so fix hingebogen das es irgendwie läuft. So jedenfalls lese ich den Entwicklerkommentar.

Ist in etwas das gleiche als man damals den DX9 Engines einfach mal DX10/11 untergeschoben hat und sich gewundert hat warum es nicht gebracht hat.

[M4xw0lf]

Nunja, es läuft - für day 1 ist das doch nicht zu übel. ^^

[Demirug]

Nunja, es läuft - für day 1 ist das doch nicht zu übel. ^^

Das habe ich bei DX11 aber besser hinbekommen.

[M4xw0lf]

Das habe ich bei DX11 aber besser hinbekommen.
Ich erinnere mich. http://www.pcgameshardware.de/DirectX-11-Software-233669/Tests/Praxis-Tipps-und-Benchmarks-697233/
Aber wie viel Vorlaufzeit hattet ihr damals?

[Achill]

Noch ein interessanten Artikel auf GPUOpen entdeckt: Vulkan+Renderpasses (http://gpuopen.com/vulkan-renderpasses/)

Ich könnte es praktisch nicht anwenden aber wäre folgender Vergleich passend (für die Forward Renderer):
Anstatt eine Datenstruktur im Heap (Textur) zu erzeugen, verbleibt diese lokal bzw. als Funktionsargument auf dem Stack - damit ist der Scope bekannt und es können Optimierungen wie beim Zugriff (keine Barriere bei konkurierenden Zugriff) / Daten bleigen in Register/Cache gemacht werden?

[Loeschzwerg]

64 Bit Version gestartet und Vulkan-Treiber installiert?
64 Bit muss man bei dem Spiel leider immer vor jedem Start über Steam als Launcher auswählen.

Ich musste den Treiber neu installieren, warum auch immer.

Ergebnis mit Xeon E5 v3 14 cores @ 2.5GHz und R9 Nano; alles Ultra und 4x MSAA:
D3D11 -> 99.8 avg. fps
Vulkan -> 65.4 avg. fps

Unter Vulkan zuckelt es noch seltsam, aber Grafikfehler gab es soweit keine. Es fehlt halt noch der letzte Schliff.

[aufkrawall]

Da fehlt noch wesentlich mehr ;) :
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10945283#post10945283

[Loeschzwerg]

Danke, hatte ich überlesen.

Dann korrigiere ich mich, man hat nen Felsbrocken mit eingeschlossenem Diamant gefunden und die restliche Arbeit steht noch bevor ^^

[z3ck3]

p.s. kein Vulcan Treiber für die GTX570. Ich geh jetzt Schokolade kaufen. :'(

[Achill]

p.s. kein Vulcan Treiber für die GTX570. Ich geh jetzt Schokolade kaufen. :'(

Komm doch dann bei "Kaufberatung und Wertanfragen" vorbei und bring die Schoki mit.

[Kartenlehrling]

p.s. kein Vulcan Treiber für die GTX570. Ich geh jetzt Schokolade kaufen. :'(

muss ja nicht ... Nvidia hat nur 100% DX12 versprochen (http://de.slideshare.net/revolutioncomputer/nuevo-driver-nvidia-337-mejoras) :biggrin:

[Ganon]

RetroArch hat jetzt in der Entwickler-Version auch ein Vulkan-Backend:

https://github.com/libretro/RetroArch/pull/2729

[Kartenlehrling]

Wie sieht es mit Overlay Tools aus zum aufzeichnen und anzeigen der GPU+CPU ?

[kruemelmonster]

Porting a Graphics Engine to the Vulkan API (https://community.arm.com/groups/arm-mali-graphics/blog/2016/02/16/porting-a-graphics-engine-to-the-vulkan-api)

[Avalox]

NVidia Android Vulkan Page mit Demos

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

[M4xw0lf]

Lol, super FAQ von Croteam bei Steam (sehr lang, daher spoiler):
Q: What is this Vulkan, anyway?

A: Vulkan is a great new graphics programming interface that has much less overhead compared to previous APIs like Direct3D 9, 11 or OpenGL.


Q: Oh, so it's like Direct3D 12?

A: Quite like it, but portable, and not restricted to Windows 10 OS.


Q: I see. Like Apple Metal?

A: That too. But again, portable, and not restricted to iOS and OS X.


Q: So, it's like Mantle then?

A: Right again. But portable, not restricted to just one GPU vendor. And Mantle is pretty much gone. It served its purpose to get things started and I think that a lot of Mantle is now incorporated into Vulkan.


Q: Uh! Let's try this one more time. What's Vulkan again?

A: A PORTABLE low-level graphics API, that works across many GPU vendors (NVIDIA, AMD, Intel, Qualcomm, PowerVR...) and OSes (Windows, Linux, Android).


Q: That's better. Now, why was Vulkan support added to Talos?

A: Good question! We (Croteam) firmly believe that Vulkan is really the best low(est)-level API there can be. Fast and portable!
Yes, it has downside(s). For one, it's quite hard to program for. You have to do a lot of things manually, instead of relying on drivers to do the work for you. This is both good and bad at the same time. Good for performance reasons, because driver doesn't assume what game wants to render (I won't go into any more details here, sorry). Bad because there's a lot more coding and in general, it's a more complex approach. You better know what you're doing, because you won't get any help from the driver. You're on your own.
It's really great to have that much control. IF you know what you're doing!


Q: So, we can expect new super-duper graphics effects and more explosions?

A: No, this is graphics _programming_ interface, not effects designer. The Talos Principle will look exactly the same as on other gfx APIs (Direct3D 9 and 11, and OpenGL). At least it should. Otherwise it's a bug! Except if it looks better û then we'll just call it a feature. :)


Q: Why should I try it, or buy it?

A: First, because The Talos Principle is a great game! Believe me - I've played it! :)
On a more serious note, we (Croteam) are kinda expecting your assistance to find bugs and performance issues with different GPUs. We were only able to test the game with a few cards and we would like to know û how does it run on your end?


Q: I'm a beta tester? Again? For free?

A: Well, yes. But only if you want to be. We (Croteam) really need some more assistance from our great community because, well, programming Vulkan is very complex! I'm still not sure if I did everything right. Our entire GPU department was hard at work for three whole months. It's that hard!
Or maybe there's something in the fact that our GPU department is comprised of just one guy. It's me! Hi!


Q: So, OpenGL is dead?

A: No, not at all. For simple games, OpenGL (or Direct3D for that matter) is here to stay; learning curve is not that steep as with Vulkan. However, Vulkan really shines when it comes to reducing application and driver CPU overhead. It is (or will be) much faster than Direct3D 9, 11 and OpenGL!


Q: Then I can expect some great benchmark results?

A: Not so fast! Sorry. :( This is a beta phase, and there's still work to be done from our (Croteam) side and IHVs from driver side. But please be patient: in time, after optimizations are done, Vulkan will be faster, I'm sure.


Q: Really?

A: Let me put it this way: When The Talos Principle came out, it had a very similar frame rate in DirectX 9 vs DX 11. But then we optimized the game, and the drivers were optimized in the meantime, and now D3D11 is 20-30% faster than D3D9! I have a firm belief that this will also happen to Vulkan vs D3D11, over time However, for now you can actually expect lower frame-rate compared to D3D11. C'mon, it's brand new API, give it some time. :)


Q: Cut to the chase, please!

A: Ok, first, in GPU-bound scenarios (ultra settings, resolution higher than full HD), you'll see lower performance, 20 to 30% lower. This is work in progress, and we (both Croteam and IHVs) are analyzing and optimizing the performance. We'll get to the bottom of this!


Q: And CPU-bound scenarios?

A: Same or a bit faster. But for now, those scenarios really have to be super-CPU-bound. Like, rendering whole levels, without any help from visibility system, frustum, distance or occlusion culling.


Q: That bad, a?

A: Well, not that much. At least, this is how I tested when wanted to see what Vulkan can do.


Q: I think I've been patient enough - can I go and benchmark now?

A: Yes, you can. But I repeat - don't have high hopes. At least not for now.


Q: Good, finally. Ok, what do I need?

A: Well, drivers. They should be available from nVidia and AMD. Download, install, run, duck'n'cover. :)


Q: Should I reboot the system after installing drivers?

A: I'm not sure, but better reboot. With Windows, if you're in doubt - reboot!


Q: nVidia, AMD, AMD, nVidia... wait! What about Intel?!

A: Driver should be available soon. We're still trying to test it and make it run well. Or just make it run, for that matter.


Q: That's all?

A: No, you also need to run 64-bit version of The Talos Principle.


Q: Wait, what? No support for 32-bit?

A: No. 64-bit is the future. And present!


Q: Will there be Vulkan support for 32-bit version of the game?

A: Probably not.


Q: How should I...?

A: If you installed driver correctly, there should be "Vulkan (beta)" in graphics API menu under Options->Graphics options. When you select it you'll get a warning message that you'll loose your warranty. Well, not exactly that, but it's kinda message to expect, well, anything!


Q: Anything, ok, anything. Anything...else?

A: Well... the game could crash or lock up here and there. But that's why we have you, folks - to report it, here in forum, attaching log files and info and everything... You know the drill, don't you? ;)


Q: Wait! There's no Vulkan support in my version of The Talos Principle?

A: You should opt-in for public beta.
To install the beta, do this:
- locate the game in the Steam's "Library" panel
- right click and invoke "Properties"
- select the "Betas" tab
- choose "publicbeta"


Q: Almost forgot - what about minimum and recommended specs to run Talos under Vulkan?

A: Oh, yes, you're right - that's important! Here:

OS: Windows 7, 8.1 or 10 (Linux later)
RAM: 8 GB (16 GB just in case)
GPU: latest generation (or one previous gen)
(NV: 770 or better, 960 or better, could work on 600 but haven't tested;
AMD: 7970, 280 or better, 370 or better, Fury)
VRAM: 1 GB (not so sure about this, better have 2 GB at least)
SOUND: doesn't matter, Vulkan is for graphics!


Q: Windows XP?

A: Probably not, sorry.


Q: Vista?

A: HAHAHAHAHHAAAAA!!! No! (Well, I wouldn't be surprise if it actually runs OK under Vista x64, but I'll be definately surprised that you have Vista in the first place!)


Q: Will Vulkan or The Talos Principle break my system?

A: No. I don't think so. Hopefully not. If/when something goes wrong, either the game will crash, or the driver itself. But no BSOD. It shouldn't happen. But don't take my word for it; go ahead - try it for yourselves, try it, go, go... :)


Q: It BSOD my system, you lying little person! What now?

A: Soooory. My bad. No, not mine. Driver's! ;)
For real, if it really BSODs couple of times, don't test anymore. No point.


Q: Oy! Talos freezes after some minutes in game.

A: Let me guess... you have Windows 10 and nVidia graphic card?


Q: Yes.

A: Well, it kinda does that from time to time. We're still investigatin the issue... Sorry again.


Q: Sorry, ok, but what should I do?

A: This could be releated to occlusion culling.


Q: Occlusion what...?

A: Culling. Nevermind, just write these console variables and it should help.
ren_bOcclusionCulling=0
shb_bOcclusionCulling=0
crm_bOcclusionCulling=0
efx_iLensFlareQuality=0
(Game will run a bit slower, though.)

Q: Console? Variables?

A: You're not power user, I'm guessing...?


Q: Well, no.

A: Console can be invoked with F1 or ~ key. And then you can write to set some settings for the game.


Q: Oooo, I see...

A: Good!


Q: I just benchmarked it. FPS is lower than D3D, why?

A: I told you so. In time... good things come to those who wait. :)


Q: Oh, almost forgot - how about Linux version?

A: Soon! It's still in a bit development and more testing needs to be done.


Q: Thank you.

A: No, thank you! In advance! For testing!


Q: Anyone else?

A: Of course! Thanks goes to all great folks at nVidia, AMD, Khronos, LunarG, Valve and RenderDoc!
Without them, I would have one triangle rendered on screen by now. Small triangle. Maybe. With errors. And wrong color. :)

Yours truly,

Dean
:D

[deekey777]

Lol, super FAQ von Croteam bei Steam (sehr lang, daher spoiler):
Q: What is this Vulkan, anyway?

A: Vulkan is a great new graphics programming interface that has much less overhead compared to previous APIs like Direct3D 9, 11 or OpenGL.


Q: Oh, so it's like Direct3D 12?

A: Quite like it, but portable, and not restricted to Windows 10 OS.


Q: I see. Like Apple Metal?

A: That too. But again, portable, and not restricted to iOS and OS X.


Q: So, it's like Mantle then?

A: Right again. But portable, not restricted to just one GPU vendor. And Mantle is pretty much gone. It served its purpose to get things started and I think that a lot of Mantle is now incorporated into Vulkan.


Q: Uh! Let's try this one more time. What's Vulkan again?

A: A PORTABLE low-level graphics API, that works across many GPU vendors (NVIDIA, AMD, Intel, Qualcomm, PowerVR...) and OSes (Windows, Linux, Android).


Q: That's better. Now, why was Vulkan support added to Talos?

A: Good question! We (Croteam) firmly believe that Vulkan is really the best low(est)-level API there can be. Fast and portable!
Yes, it has downside(s). For one, it's quite hard to program for. You have to do a lot of things manually, instead of relying on drivers to do the work for you. This is both good and bad at the same time. Good for performance reasons, because driver doesn't assume what game wants to render (I won't go into any more details here, sorry). Bad because there's a lot more coding and in general, it's a more complex approach. You better know what you're doing, because you won't get any help from the driver. You're on your own.
It's really great to have that much control. IF you know what you're doing!


Q: So, we can expect new super-duper graphics effects and more explosions?

A: No, this is graphics _programming_ interface, not effects designer. The Talos Principle will look exactly the same as on other gfx APIs (Direct3D 9 and 11, and OpenGL). At least it should. Otherwise it's a bug! Except if it looks better û then we'll just call it a feature. :)


Q: Why should I try it, or buy it?

A: First, because The Talos Principle is a great game! Believe me - I've played it! :)
On a more serious note, we (Croteam) are kinda expecting your assistance to find bugs and performance issues with different GPUs. We were only able to test the game with a few cards and we would like to know û how does it run on your end?


Q: I'm a beta tester? Again? For free?

A: Well, yes. But only if you want to be. We (Croteam) really need some more assistance from our great community because, well, programming Vulkan is very complex! I'm still not sure if I did everything right. Our entire GPU department was hard at work for three whole months. It's that hard!
Or maybe there's something in the fact that our GPU department is comprised of just one guy. It's me! Hi!


Q: So, OpenGL is dead?

A: No, not at all. For simple games, OpenGL (or Direct3D for that matter) is here to stay; learning curve is not that steep as with Vulkan. However, Vulkan really shines when it comes to reducing application and driver CPU overhead. It is (or will be) much faster than Direct3D 9, 11 and OpenGL!


Q: Then I can expect some great benchmark results?

A: Not so fast! Sorry. :( This is a beta phase, and there's still work to be done from our (Croteam) side and IHVs from driver side. But please be patient: in time, after optimizations are done, Vulkan will be faster, I'm sure.


Q: Really?

A: Let me put it this way: When The Talos Principle came out, it had a very similar frame rate in DirectX 9 vs DX 11. But then we optimized the game, and the drivers were optimized in the meantime, and now D3D11 is 20-30% faster than D3D9! I have a firm belief that this will also happen to Vulkan vs D3D11, over time However, for now you can actually expect lower frame-rate compared to D3D11. C'mon, it's brand new API, give it some time. :)


Q: Cut to the chase, please!

A: Ok, first, in GPU-bound scenarios (ultra settings, resolution higher than full HD), you'll see lower performance, 20 to 30% lower. This is work in progress, and we (both Croteam and IHVs) are analyzing and optimizing the performance. We'll get to the bottom of this!


Q: And CPU-bound scenarios?

A: Same or a bit faster. But for now, those scenarios really have to be super-CPU-bound. Like, rendering whole levels, without any help from visibility system, frustum, distance or occlusion culling.


Q: That bad, a?

A: Well, not that much. At least, this is how I tested when wanted to see what Vulkan can do.


Q: I think I've been patient enough - can I go and benchmark now?

A: Yes, you can. But I repeat - don't have high hopes. At least not for now.


Q: Good, finally. Ok, what do I need?

A: Well, drivers. They should be available from nVidia and AMD. Download, install, run, duck'n'cover. :)


Q: Should I reboot the system after installing drivers?

A: I'm not sure, but better reboot. With Windows, if you're in doubt - reboot!


Q: nVidia, AMD, AMD, nVidia... wait! What about Intel?!

A: Driver should be available soon. We're still trying to test it and make it run well. Or just make it run, for that matter.


Q: That's all?

A: No, you also need to run 64-bit version of The Talos Principle.


Q: Wait, what? No support for 32-bit?

A: No. 64-bit is the future. And present!


Q: Will there be Vulkan support for 32-bit version of the game?

A: Probably not.


Q: How should I...?

A: If you installed driver correctly, there should be "Vulkan (beta)" in graphics API menu under Options->Graphics options. When you select it you'll get a warning message that you'll loose your warranty. Well, not exactly that, but it's kinda message to expect, well, anything!


Q: Anything, ok, anything. Anything...else?

A: Well... the game could crash or lock up here and there. But that's why we have you, folks - to report it, here in forum, attaching log files and info and everything... You know the drill, don't you? ;)


Q: Wait! There's no Vulkan support in my version of The Talos Principle?

A: You should opt-in for public beta.
To install the beta, do this:
- locate the game in the Steam's "Library" panel
- right click and invoke "Properties"
- select the "Betas" tab
- choose "publicbeta"


Q: Almost forgot - what about minimum and recommended specs to run Talos under Vulkan?

A: Oh, yes, you're right - that's important! Here:

OS: Windows 7, 8.1 or 10 (Linux later)
RAM: 8 GB (16 GB just in case)
GPU: latest generation (or one previous gen)
(NV: 770 or better, 960 or better, could work on 600 but haven't tested;
AMD: 7970, 280 or better, 370 or better, Fury)
VRAM: 1 GB (not so sure about this, better have 2 GB at least)
SOUND: doesn't matter, Vulkan is for graphics!


Q: Windows XP?

A: Probably not, sorry.


Q: Vista?

A: HAHAHAHAHHAAAAA!!! No! (Well, I wouldn't be surprise if it actually runs OK under Vista x64, but I'll be definately surprised that you have Vista in the first place!)


Q: Will Vulkan or The Talos Principle break my system?

A: No. I don't think so. Hopefully not. If/when something goes wrong, either the game will crash, or the driver itself. But no BSOD. It shouldn't happen. But don't take my word for it; go ahead - try it for yourselves, try it, go, go... :)


Q: It BSOD my system, you lying little person! What now?

A: Soooory. My bad. No, not mine. Driver's! ;)
For real, if it really BSODs couple of times, don't test anymore. No point.


Q: Oy! Talos freezes after some minutes in game.

A: Let me guess... you have Windows 10 and nVidia graphic card?


Q: Yes.

A: Well, it kinda does that from time to time. We're still investigatin the issue... Sorry again.


Q: Sorry, ok, but what should I do?

A: This could be releated to occlusion culling.


Q: Occlusion what...?

A: Culling. Nevermind, just write these console variables and it should help.
ren_bOcclusionCulling=0
shb_bOcclusionCulling=0
crm_bOcclusionCulling=0
efx_iLensFlareQuality=0
(Game will run a bit slower, though.)

Q: Console? Variables?

A: You're not power user, I'm guessing...?


Q: Well, no.

A: Console can be invoked with F1 or ~ key. And then you can write to set some settings for the game.


Q: Oooo, I see...

A: Good!


Q: I just benchmarked it. FPS is lower than D3D, why?

A: I told you so. In time... good things come to those who wait. :)


Q: Oh, almost forgot - how about Linux version?

A: Soon! It's still in a bit development and more testing needs to be done.


Q: Thank you.

A: No, thank you! In advance! For testing!


Q: Anyone else?

A: Of course! Thanks goes to all great folks at nVidia, AMD, Khronos, LunarG, Valve and RenderDoc!
Without them, I would have one triangle rendered on screen by now. Small triangle. Maybe. With errors. And wrong color. :)

Yours truly,

Dean
:D

Und was ist dann der Sinn das Spiel auf Vulcan zu portieren?
Windows XP und Vista werden nicht unterstützt, sondern Windows 7 und neuer, dafür gibt es bereits DX11, was nach und nach schneller geworden ist als DX9. Jetzt betreibt man einen Aufwand, damit das Spiel irgendwann mindestens so schnell läuft wie DX11, vielleicht ergeben sich bessere Effekte. Ist Croteam irgendwie nicht ausgelastet?

[N0Thing]

Besser die Probleme Stück für Stück mit einer Beta eines fertigen Spiels kennen lernen und Erfahrung sammeln, als den nächsten Titel verbuggt und mit schlechter Performance auf die Kunden los zu lassen.
Außerdem bekommen sie so mehr Aufmerksamkeit in den Medien und verkaufen dadurch sicher zusätzlich noch die eine oder andere Lizenz von The Talos Principle.

[Kartenlehrling]

Was halt gar nicht geht wenn selbst (Nvidia?) Demos Singlecore laufen.

http://www.computerbase.de/forum/showthread.php?t=1560561&page=4&p=18486664#post18486664
Chopper Demo
https://developer.nvidia.com/Vulkan
Nvidia Demo

[derF]

Das hätte aber Tradition. CPU-PhysX...

[deekey777]

Was halt gar nicht geht wenn selbst (Nvidia?) Demos Singlecore laufen.

http://www.computerbase.de/forum/showthread.php?t=1560561&page=4&p=18486664#post18486664
Chopper Demo
https://developer.nvidia.com/Vulkan
Nvidia Demo
Kannst du etwas näher ausführen, was dich so aufregt?

[Lord_X]

http://steamcommunity.com/app/257510/discussions/0/412447331651720139/

... Our entire GPU department was hard at work for three whole months. It's that hard! Or maybe there's something in the fact that our GPU department is comprised of just one guy...

^^ 3 Monate hat ein einzelnel Mann an der Umsetzung von Vulkan gearbeitet. Ich finde das sehr bemerkenswert, dass es damit schon besser als OpenGL läuft :up:

[Lurtz]

Und was ist dann der Sinn das Spiel auf Vulcan zu portieren?
Windows XP und Vista werden nicht unterstützt, sondern Windows 7 und neuer, dafür gibt es bereits DX11, was nach und nach schneller geworden ist als DX9. Jetzt betreibt man einen Aufwand, damit das Spiel irgendwann mindestens so schnell läuft wie DX11, vielleicht ergeben sich bessere Effekte. Ist Croteam irgendwie nicht ausgelastet?
Ein Mann hat daran gearbeitet. Das wird selbst Croteam nicht auslasten. Und da Croteam in Zukunft auf Vulkan setzen möchte (sie haben ja schon immer gern für mehrere Systeme veröffentlicht) und das bei Serious Sam 4 denke ich schon die best optimierte API werden soll, macht das absolut Sinn für sie bei Talos zu "üben".

[iuno]

Kannst du etwas näher ausführen, was dich so aufregt?
Hast du den Link angeklickt? Es stoert ihn offenbar, dass die Demo komplett CPU-Limitiert ist, weil Nvidia hier offenbar nur einen Thread benutzt. Fuer eine Vulkan-Demo ist das tatsaechlich denkbar unguenstig

3 Monate hat ein einzelnel Mann an der Umsetzung von Vulkan gearbeitet. Ich finde das sehr bemerkenswert, dass es damit schon besser als OpenGL läuft :up:
Weisst du denn, wie viel in die OGL Umsetzung investiert wurde?

[Demirug]

Ich erinnere mich. http://www.pcgameshardware.de/DirectX-11-Software-233669/Tests/Praxis-Tipps-und-Benchmarks-697233/
Aber wie viel Vorlaufzeit hattet ihr damals?

So genau kann ich mich daran nicht erinnern. Das war auch nicht das Problem da wir eigentlich nur auf Hardware von AMD und die Freigabe von Microsoft gewartet haben als es schon lange fertig programmiert war.

Noch ein interessanten Artikel auf GPUOpen entdeckt: Vulkan+Renderpasses (http://gpuopen.com/vulkan-renderpasses/)

Ich könnte es praktisch nicht anwenden aber wäre folgender Vergleich passend (für die Forward Renderer):
Anstatt eine Datenstruktur im Heap (Textur) zu erzeugen, verbleibt diese lokal bzw. als Funktionsargument auf dem Stack - damit ist der Scope bekannt und es können Optimierungen wie beim Zugriff (keine Barriere bei konkurierenden Zugriff) / Daten bleigen in Register/Cache gemacht werden?

Es geht hier ja um den Zugriff auf die Datenstrukturen. Dafür ist völlig egal wo diese liegen. Man müsste also den Code analysieren. In gewissem Umfang passiert sowas ja im Bereich der Auto Vektorisierung und Auto Parallelisierung.

Für das was dort beschrieben wird gibt es aber auch durchaus Frameworks für die CPU. Dort müssen dann für jeden Task/Job definiert werden welche Objekte wie benutzt werden (Read/Write/Read+Write) und der Framework kann dann die Tasks so sortieren das sie ohne locking mit maximaler parralelität ausgeführt werden.

Man kann das ganze aber auch mit klassischen Render APIs wie OpenGL/DX11 machen. Das Problem dort ist nur das es aufwendiger ist die Analyse auf andere Threads zu verschieben was dann zu einem hohen Submit overhead führt wenn die Analyse am Ende eines Frames (oder jeweils beim wechsel des Targets) im Renderthread erfolgt. Da bei Vulkan die Subpasses ja explizit definiert sind kann die Analyse direkt in dem Thread erfolgen welcher den Subpass erzeugt.

[Troyan]

Hast du den Link angeklickt? Es stoert ihn offenbar, dass die Demo komplett CPU-Limitiert ist, weil Nvidia hier offenbar nur einen Thread benutzt. Fuer eine Vulkan-Demo ist das tatsaechlich denkbar unguenstig


Dies ist eine Funktionalität der API und keine Voraussetzung...

nVidia hat auch eine reine Multi-Thread Rendering Demo zur Verfügung gestellt, die perfekt über alle Threads skaliert:
https://developer.nvidia.com/vulkan-android#samples

[Stebs]

Laut PCPer liegts an NV bzw dem niedrigen Marktanteil der Fermis
@Blaire: Bitte am Ball bleiben. :biggrin:
p.s. kein Vulcan Treiber für die GTX570. Ich geh jetzt Schokolade kaufen. :'(
Also zumindest in SaschaWs Datenbank (http://vulkan.gpuinfo.org/) finden sich ja auch einige Einträge von Fermi-Karten :biggrin:

@SaschaW

Kannst/darfst du dazu was sagen? :udevil:
Oder zumindest: Was bedeutet es wenn "residencyStandard3DBlockShape" vom Treiber nicht unterstützt wird? Ist er dann trotzdem komplett Vulkan fähig?

[Noch am Rande: In einigen Tagen, Wochen? hast du ja evtl. mal wieder Zeit/Lust an glCapsViewer zu schrauben, da gibt es in den Issues auf github nun einen Eintrag + Fix, damit der core Context nun eendlich auch mit mesa funktioniert!
Bei mir klappt das kompilieren unter linux leider nicht, aber das könnte auch gut an mir liegen]

[M4xw0lf]

So genau kann ich mich daran nicht erinnern. Das war auch nicht das Problem da wir eigentlich nur auf Hardware von AMD und die Freigabe von Microsoft gewartet haben als es schon lange fertig programmiert war.
Bei Croteam hat ein Einzelner drei Monate für den jetzigen Stand der Vulkan-Implementierung gebastelt... klingt ziemlich aufwendig.

[Demirug]

Bei Croteam hat ein Einzelner drei Monate für den jetzigen Stand der Vulkan-Implementierung gebastelt... klingt ziemlich aufwendig.

Man muss jetzt halt sehr viel selbst machen was vorher der Treiber gemacht hat. Hinzu kommt noch das die Tools, SDK, etc während der Zeit ja auch noch im entstehen waren. Das macht es nicht einfacher.

[deekey777]

Also zumindest in SaschaWs Datenbank (http://vulkan.gpuinfo.org/) finden sich ja auch einige Einträge von Fermi-Karten :biggrin:


Ich verstehe die Angaben auf der Seite so, dass es nur die Hardware-Fähigkeit überprüft wird, also was mit Vulkan möglich wäre. Ohne Treiber - kein Vulcan auf Fermi.

Man muss jetzt halt sehr viel selbst machen was vorher der Treiber gemacht hat. Hinzu kommt noch das die Tools, SDK, etc während der Zeit ja auch noch im entstehen waren. Das macht es nicht einfacher.
Werden dadurch Anforderungen an Programmierer steigen, die, sofern und soweit sie über die entsprechenden Qualifikationen verfügen, auch besser bezahlt werden dürfen?

[SaschaW]

Ich verstehe die Angaben auf der Seite so, dass es nur die Hardware-Fähigkeit überprüft wird, also was mit Vulkan möglich wäre. Ohne Treiber - kein Vulcan auf Fermi.

Hab grade mit NVIDIA gesprochen, der Fermi-Report ist Fake. Der Vulkan Caps Viewer benötigt schon ein funktionierendes Vulkan, zumindest bis zum Abrufen der Hardware Infos wie Queues, etc. D.h. er erzeugt eine Vulkan Instanz und ein Vulkan Device, an das man nur kommt wenn ein Vulkan ICD installiert ist.

Da der aber Open Source ist kann man damit durchaus Reports faken, und leider gibts im Netz halt in allen Bereichen Trolle. Wer wollte könnte vermutlich auch über den Open Source Loader ganze Geräte faken :/

Es gibt momentan definitiv (noch) keinen Support von Vulkan auf Fermi.

[SaschaW]

Kannst/darfst du dazu was sagen? :udevil:
Oder zumindest: Was bedeutet es wenn "residencyStandard3DBlockShape" vom Treiber nicht unterstützt wird? Ist er dann trotzdem komplett Vulkan fähig?

Ja, ist er. Das ist ja nur eine Eigenschaft der Implementation. Sobald der CapsViewer läuft und ein gültiges Devicehandle bekomm (vkCreateDevice) bedeutet dies dass auch ein funktionierender ICD installiert ist.

Selbst ein Treiber der kein einziges der Features unterstützten würde könnte eine gültige Implementation sein.

[Stebs]

Hab grade mit NVIDIA gesprochen, der Fermi-Report ist Fake. Der Vulkan Caps Viewer benötigt schon ein funktionierendes Vulkan, zumindest bis zum Abrufen der Hardware Infos wie Queues, etc. D.h. er erzeugt eine Vulkan Instanz und ein Vulkan Device, an das man nur kommt wenn ein Vulkan ICD installiert ist.

Da der aber Open Source ist kann man damit durchaus Reports faken, und leider gibts im Netz halt in allen Bereichen Trolle. Wer wollte könnte vermutlich auch über den Open Source Loader ganze Geräte faken :/

Es gibt momentan definitiv (noch) keinen Support von Vulkan auf Fermi.Fakes wären aber schon komisch/heftig. :eek:

Evtl. gibts aber auch eine einfachere Erkärung (http://www.heise.de/forum/heise-Developer/News-Kommentare/3D-Schnittstelle-Vulkan-API-und-Treiber-von-AMD-und-Nvidia-erschienen/Mobile-Maxwell-Quadros-aussen-vor/thread-4187457/#posting_24537658):
Die Caps kann ich mir lustigerweise auch ausspucken lassen. Mir ist allerdings unklar ob die tatsächlich vom Treiber kommen oder von der Runtime des Vulkan-SDK von LunarG, dass ich installiert habe. Wenn ich mir da z.B. so einen mobilen Fermi anschaue (http://vulkan.gpuinfo.org/displayreport.php?id=55), dann sehe ich da unter "Layers", dass derjenige, der das hochgeladen hat das SDK offenbar ebenfalls installiert hatte.

Der Vulkan Caps Viewer zeigt mir da ähnliche Informationen an, beschwert sich aber dennoch zu Anfang, dass kein Vulkan-Device erstellt werden konnte.

[Demirug]

Werden dadurch Anforderungen an Programmierer steigen, die, sofern und soweit sie über die entsprechenden Qualifikationen verfügen, auch besser bezahlt werden dürfen?

Eher nicht. Es ist ja nicht so das die Entwickler die sich bisher damit beschäftigt haben damit nicht zurecht kommen würden. Man braucht halt einfach nur mehr Zeit bis man den benötigten Funktionsumfang programmiert hat.

[SaschaW]

Fakes wären aber schon komisch/heftig. :eek:

Evtl. gibts aber auch eine einfachere Erkärung (http://www.heise.de/forum/heise-Developer/News-Kommentare/3D-Schnittstelle-Vulkan-API-und-Treiber-von-AMD-und-Nvidia-erschienen/Mobile-Maxwell-Quadros-aussen-vor/thread-4187457/#posting_24537658):

Die Layer kommen über das SDK. D.h. ohne SDK oder mit falschem Layerpfad wird da nix angezeigt. Layer müssen aber auch zusätzlich noch vom Device unterstützt werden. Evtl. entferne ich die Reiterseite (macht eigentlich keinen Sinn mehr) oder passe den Hinweis an.

Den Rest der Daten bekommt man aber ohne gültiges Device nicht. Momentan gibt es aber noch ein paar kleine Bugs wenn man mehrere Devices hat (z.B. Intel IGP + diskrete GPU), evtl. kann man auch dadrüber noch was faken, wobei dann der Vendor nicht mehr passen würde.

Wenn es in Zukunft mehr Fakes geben sollte nehme ich den Quellcode für die Anwendung evtl. aus dem Netz, oder erlaube den Upload auf die echte DB nur noch über eine "signierte" Version. Wäre halt schade, weil ich damit dann die Platformreichweite einschränken würde.

[S940]

Und was ist dann der Sinn das Spiel auf Vulcan zu portieren?
Windows XP und Vista werden nicht unterstützt, sondern Windows 7 und neuer, dafür gibt es bereits DX11, was nach und nach schneller geworden ist als DX9. Jetzt betreibt man einen Aufwand, damit das Spiel irgendwann mindestens so schnell läuft wie DX11, vielleicht ergeben sich bessere Effekte. Ist Croteam irgendwie nicht ausgelastet?
Wo ist das Problem? Statt DX11 gibts bekanntlich schon das abermals bessere DX12 und Vulkan ist sowas wie DX12, nur halt für alle OSe.

Also das Beste für Jeden. Natürlich will man das als Softwarehersteller haben, da dann der Absatzmarkt größer ist. Games lassen sich dann schnell unter Win und Mobilgeräten verkaufen, als Nebeneffekt werden noch ein paar Linux-Gamer beglückt. Und das Beste: Nur ein kleiner Mehraufwand.

[Stebs]

Wenn es in Zukunft mehr Fakes geben sollte nehme ich den Quellcode für die Anwendung evtl. aus dem Netz, oder erlaube den Upload auf die echte DB nur noch über eine "signierte" Version. Wäre halt schade, weil ich damit dann die Platformreichweite einschränken würde.Nenn mich zu vertrauensselig, aber irgendwie habe ich noch immer das Gefühl, diese Einträge sind keine absichtlichen Fakes...
Auffällig ist dabei die fehlende Angabe des Betriebsystems.
Evtl. findet sich ja doch noch eine Erklärung wie die entstehen können, ohne manuelle Fakes zu sein.

Wie auch immer, die stören ja 0,0, ich würde erstmal alles so lassen.
War mir eben nur in der Fermi-Frage gleich aufgefallen, aber das ist ja nun geklärt.
Zur Not könntest du evtl. noch ein "Fermi kann momentan kein Vulkan!" Hinweis oben in die Datenbank schreiben, bin wohl auf Dauer nicht der einzige Depp dem die Fermi-Einträge auffallen...

[S940]

Man muss jetzt halt sehr viel selbst machen was vorher der Treiber gemacht hat. Hinzu kommt noch das die Tools, SDK, etc während der Zeit ja auch noch im entstehen waren. Das macht es nicht einfacher.Ja, wenn man das Rad neu erfinden will muss man das halt so machen. Allerdings bestünde auch die Möglichkeit eine Engine zu lizenzieren. Von denen wirds in Zukunft sicherlich auch eine Menge Vulkan-kompatibler Versionen geben. Sieht man auch schön in der Grafik der Präsentation:
http://abload.de/img/vulkan_16ndz7u.jpg

[d2kx]

Intel Skylake Vulkan Support Appears To Be Working Out Pretty Well (http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.0-SKL-First-Test)

[SaschaW]

Nenn mich zu vertrauensselig, aber irgendwie habe ich noch immer das Gefühl, diese Einträge sind keine absichtlichen Fakes...
Auffällig ist dabei die fehlende Angabe des Betriebsystems.
Evtl. findet sich ja doch noch eine Erklärung wie die entstehen können, ohne manuelle Fakes zu sein.

Wie auch immer, die stören ja 0,0, ich würde erstmal alles so lassen.
War mir eben nur in der Fermi-Frage gleich aufgefallen, aber das ist ja nun geklärt.
Zur Not könntest du evtl. noch ein "Fermi kann momentan kein Vulkan!" Hinweis oben in die Datenbank schreiben, bin wohl auf Dauer nicht der einzige Depp dem die Fermi-Einträge auffallen...

Die "gefakten" Reports unterstützten allesamt 0 Formate. Evtl. kommen diese Reports durch einen Bug im CapsViewer zustande der auftreten kann wenn man mehrere GPUs im System hat und dann wechselt, da wird ggf. nicht alles sauber aufgeräumt.

Hat man nur eine GPU die kein Vulkan unterstützt startet die Anwendung nicht.

Ich werde vorerst also den Upload so anpassen (server-seitig) dass Reports ohne ein einziges unterstütztes Format nicht hochgeladen werden können, und den CapsViewer dann auch noch fixen.

Das ist der sicherste Weg, denn eine Vulkan-Implementation ohne unterstützte Format kann man nicht nutzen. Damit bekommt man weder einen Farb- noch einen Tiefenpuffer, und selbst wenn man die nicht bräuchte (z.B. nur Compute) wäre auch kein unterstütztes Bufferformat da um Daten auf die GPU hochzuladen.

[Stebs]

Hat man nur eine GPU die kein Vulkan unterstützt startet die Anwendung nicht.Jepp:
./vulkanCapsViewer: error while loading shared libraries: libvulkan.so.1: cannot open shared object file: No such file or directory
Was ja auch kein Wunder ist auf einem System mit altem Nvidia-Treiber und Fermi.

Jedenfalls zumindest soweit läuft VulkanCapsViewer bei mir. Und danke für das fertige Binary auch für uns Linuxer :)

Der Datenbank-Fix und Programm-Fix klingt vernünftig, wohl das Beste bevor das ganze noch unnötig Wellen schlägt.
Habe im Heise-Forum auch nochmals ausdrücklich darauf verwiesen dass es "Fakes" sind (leider kann ich den ursprünglichen Post nicht mehr editieren - das war früher bei Heise doch mal anders?).

[SaschaW]

Jedenfalls zumindest soweit läuft VulkanCapsViewer bei mir. Und danke für das fertige Binary auch für uns Linuxer :)

Gerne, grade bei Vulkan wars von Anfang an mein Ziel dass mein Kram auch auf Linux läuft. Für meine Beispiele gabs auch direkt Binaries für Linux (x64), und Vulkan ist mit ein Grund warum ich jetzt nicht mehr so oft ins Windows boote.

Ich hoffe mal das Linux mit Vulkan im Bereich Gaming und Multimedia jetzt mit Vulkan nen großen Schritt macht und die Zeiten in denen die OpenGL Ports grottig lahm sind bald vorbei sind :)

[Chris Lux]

Gerne, grade bei Vulkan wars von Anfang an mein Ziel dass mein Kram auch auf Linux läuft. Für meine Beispiele gabs auch direkt Binaries für Linux (x64), und Vulkan ist mit ein Grund warum ich jetzt nicht mehr so oft ins Windows boote.

Ich hoffe mal das Linux mit Vulkan im Bereich Gaming und Multimedia jetzt mit Vulkan nen großen Schritt macht und die Zeiten in denen die OpenGL Ports grottig lahm sind bald vorbei sind :)
Was hat dich mit OpenGL daran gehindert, was Vulkan jetzt unter Linux besser macht? Die AMD/Intel Treiber?

[Kartenlehrling]

https://gfxbench.com/news_single.jsp?id=25230662
GFXBench 5.0 is our new graphics benchmark designed to measure and compare the performance of recent low-level APIs including Vulkan, Metal and DX12.


Ich finde diesen Vulkan Release enttäuschender als DX12 oder Mantle je waren.
Ein Jahr Benchmark angekündig und immer noch keine download von GFXBench 5.0

[Locuza]

https://gfxbench.com/news_single.jsp?id=25230662
GFXBench 5.0 is our new graphics benchmark designed to measure and compare the performance of recent low-level APIs including Vulkan, Metal and DX12.

Ich finde diesen Vulkan Release enttäuschender als DX12 oder Mantle je waren.
Ein Jahr Benchmark angekündig und immer noch keine download von GFXBench 5.0
Ich bewundere die Kunst von einigen so konzentrierten Unsinn, in so wenig Text zu stecken. :redface:
Tief in sich blicken, ein paar Reality Checks machen und schon passt das mit den Erwartungen und Enttäuschungen deutlich besser.

[iuno]

Sehe dein Problem nicht. Ein Benchmark soll stabil und performant sein aber vor allem reproduzierbare und vergleichbare Ergebnisse liefern. Aktuell ist das halt noch nicht drin und das gilt im Uebrigen nicht nur fuer Vulkan, sondern auch fuer DX12. Ein Benchmark Release zum jetzigen Zeitpunkt waere doch absolut hirnrissig.
Die sollen sich Zeit lassen und was gescheites bringen

[Loeschzwerg]

Stimmt schon, aber dann hätte man sich ja gesamt mit dem Vulkan Release mehr Zeit lassen können, oder nicht? Damit die Treiber noch mehr reifen können und evtl. ein paar Progrämmchen am Start sind.

Gibt es von Intel schon Treiber für Windows?

[Tesseract]

Stimmt schon, aber dann hätte man sich ja gesamt mit dem Vulkan Release mehr Zeit lassen können, oder nicht? Damit die Treiber noch mehr reifen können und evtl. ein paar Progrämmchen am Start sind.

je später du eine API rausbringst umso länger dauert es bis programme dafür kommen weil viele entwickler die API mit dem offiziellen release auch zum ersten mal zu sehen bekommen. um mit dem implementieren beginnen zu können braucht man keine ausgereiften treiber. wichtig ist eigentlich nur, dass die API selbst schon fix ist.

[Loeschzwerg]

Schon klar, aber wie steht es mit einer Closed Beta um wenigstens ein paar Vorzeigeprogramme (Edit: Windows/Linux) zu haben? So ein Benchmark macht sich doch immer gut oder irgendwelche Techdemos.

Ich meine, so ist das ganze jetzt in der Presse angekommen, aber wirklich zeigen konnte man nichts (Talos läuft, woohoo ^^). Alles was jetzt kommt hat nicht mehr den gleichen Effekt wie der "Release" bzw. man tut sich wesentlich schwerer Aufmerksamkeit zu bekommen.

[Locuza]

Ohne Closed-Beta hätte es den Beta-Branch von The Talos Principle ja nicht gegeben ;)
Und DX12 mangelt es auch bisher an Software.
Und zu Vulkan gibt es eine handvoll (simpler) Techdemos von den IHVs.
Da gibt es mehr zum gucken, als beim DX12 Launch auf Seiten der IHVs.

[Tesseract]

der ganze release ist auch überhaupt nicht an enduser gerichtet. die techseiten nehmen es in die news auf damit sie halt was zu schreiben haben, aber im grunde betrifft es doch sowieso die wenigsten bis tatsächlich die ersten spiele mit vulkan rauskommen.

[Loeschzwerg]

Gut, ich habe da vielleicht zu sehr eine Unternehmerbrille auf. Ein Launch/Release muss für mich ein richtiger "Schlag ins Gesicht" (im positiven Sinne) sein :)

[deekey777]

https://gfxbench.com/news_single.jsp?id=25230662
GFXBench 5.0 is our new graphics benchmark designed to measure and compare the performance of recent low-level APIs including Vulkan, Metal and DX12.


Ich finde diesen Vulkan Release enttäuschender als DX12 oder Mantle je waren.
Ein Jahr Benchmark angekündig und immer noch keine download von GFXBench 5.0

Kishonti hat ja in den letzten Monaten nüschts geleistet.

[Kartenlehrling]

@Loeschzwerg
Hier brauch nichts zu Reifen, ist ja schliesslich kein Käse, ....ausser was man daraus macht.

Laut Aussage hatte man für Talos drei Monat Zeit für die Vulkan Portierung gehabt,
das wär genau der 18.12.2015, diesen man auch als ersten Release Termin eingeplant hatte.
Somit stand anfang Dezember wohl schon eine lauffähige Vulkan SDK bereit, aber es fehlt wohl am vorzeigbaren Material.

Ich frag mich halt wieso man nicht soo ein "einfaches" Resogun (PS4) zum Release wenigsten vorzeigen kann für den PC?
Stattdessen gibt es eine Android Hubschrauber demo die auch noch Singlecore läuft.

http://www.gamingenthusiast.net/wp-content/uploads/2013/11/Resogun-victory-GIF.gif

[Loeschzwerg]

Jup, nichts anderes wollte ich zum Ausdruck bringen.

[SaschaW]

Laut Aussage hatte man für Talos drei Monat Zeit für die Vulkan Portierung gehabt,
das wär genau der 18.12.2015, diesen man auch als ersten Release Termin eingeplant hatte.
Somit stand anfang Dezember wohl schon eine lauffähige Vulkan SDK bereit, aber es fehlt wohl am vorzeigbaren Material.
So einfach ist das nicht. Lauffähiges SDK Und Treiber gabs schon viel früher, aber nichts fertiges.

Ich frag mich halt wieso man nicht soo ein "einfaches" Resogun (PS4) zum Release wenigsten vorzeigen kann für den PC?
Stattdessen gibt es eine Android Hubschrauber demo die auch noch Singlecore läuft.

Weil man erstmal eine API entwickeln muss. Geht mir ja auch so. Wenn ich rein Vulkan Beispiele entwickelt hätte, wären es viel mehr geworden. Aber über das knappe 3/4 Jahr in dem ich beteiligt war hat sich viel an der API getan, es wurden viele Treiberbugs gefixt, etc.

Wie hier ja schon treffend gesagt wurde : Es geht nicht um einen Launch mit viel Bling-Bling der dann gut in der Presse aussieht. Das ist ein Launch der für die Entwickler gedacht ist, und wenn man bedankt was hier in so kurzer Zeit geleistet wurde ist das was gestern veröffentlicht wurde schon verdammt gut.

Die meisten Leute vergessen halt was während der Entwicklung eines solchen Projektes im Hintergrund passiert und das man Ressourcen entsprechend einteilen muss.

[Kartenlehrling]

Es wird doch behaupte das die Grundlage auf Mantle (3 Jahre) aufgebaut ist,
somit hat man das Rad nicht neu erfunden und muss von Null anfangen.
Bei DX12 behaupte doch Nvidia das sie sie seit 2009 also 7 jahre daran arbeiten.

[SaschaW]

Es wird doch behaupte das die Grundlage auf Mantle (3 Jahre) aufgebaut ist,
somit hat man das Rad nicht neu erfunden und muss von Null anfangen.
Bei DX12 behaupte doch Nvidia das sie sie seit 2009 also 7 jahre daran arbeiten.

Mantle war nur ein IHV und eigentlich nur eine GPU-Architektur (GCN). Vulkan hat ein viel breiteres Spektrum. Wirklich viel ist von Mantle nicht mehr übrig.

[aufkrawall]

Stattdessen gibt es eine Android Hubschrauber demo die auch noch Singlecore läuft.

Die Fischschwarm-Demo skaliert mit acht Threads. Ein 4770k schafft mit 100.000 Fischen immer noch mindestens 75fps, sofern man sie nicht "explodieren" lässt.
Find das zu Demonstrationszwecken gelungen.

[Loeschzwerg]

@Sascha: Benötigst du Feedback bezüglich deiner Demos? Unter Win10 x64 + R9 Nano läuft zumindest nicht alles fehlerfrei. Aber sind sonst schön gemacht :)

Edit: Die NV Demos funktionieren mit AMD Hardware nicht, zumindest bei mir.

[Ganon]

In Sachen OpenCL ist der NVidia Treiber sicherlich weiterhin auf Stand 1.2 oder?

[iuno]

Gut, ich habe da vielleicht zu sehr eine Unternehmerbrille auf. Ein Launch/Release muss für mich ein richtiger "Schlag ins Gesicht" (im positiven Sinne) sein :)
Die Khronos Group verkauft aber nichts.
Der Launch den du meinst, kommt mit dem ersten Spiel, das/dessen Engine von Grund auf (mit) fuer Vulkan gebaut wurde.

Laut Aussage hatte man für Talos drei Monat Zeit für die Vulkan Portierung gehabt,
das wär genau der 18.12.2015, diesen man auch als ersten Release Termin eingeplant hatte.
Somit stand anfang Dezember wohl schon eine lauffähige Vulkan SDK bereit, aber es fehlt wohl am vorzeigbaren Material.
Es gab schon viel frueher lauffaehige Software und auch Berichte darueber.
Warum sich der Launch verschoben hat, weiss ich nicht. Dazu kann Sascha vielleicht was sagen (falls er darf). Dass man es wegen Talos verschoben hat halte ich aber fuer ausgeschlossen, weil das einfach voelliger Quatsch ist. Das was im Hintergrund kommuniziert wurde, dass man auf bessere treiberseitige Implementierung wartet, ist dagegen wahrscheinlicher. Denn jetzt hat alle Welt Zugriff und interessierte Entwickler moechten es ja schnellstmoeglich implementieren. Zu Software gehoeren immer Tests und das geht halt nicht ohne Treiber, auch wenn man natuerlich schon voerher mit der Implementierung anfangen kann.
Wer im Dezember noch nicht bereit war, ist ja im Uebrigen sehr einfach zu erraten. :rolleyes:

Was ich aber auch sehr schade finde ist das ganze (auch in diesem Forum anzutreffende aber woanders noch viel schlimmere) Geschrei. Es wurde eine Spezifikation veroeffentlicht, kein Produkt. Es schrie ja auch keiner rum, dass es keine Grafikkarten mit HBM und GDDR5X gab, als die JEDEC die Standards veroeffentlicht hat, obwohl es ja auch schon vorher lauffaehige samples gab :rolleyes: . Ja, bei der Hardwareherstellung gibt es noch ganz andere Huerden, aber nur weil Software ein immaterielles Gut ist, heisst das nicht, dass man damit zaubern kann und von heute auf morgen mal eben weiss Gott was aus dem Boden stampft. Das Bewusstsein fehlt offenbar vielen auch 2016 noch.

In Sachen OpenCL ist der NVidia Treiber sicherlich weiterhin auf Stand 1.2 oder?
In die Richtung wurde nichts kommuniziert, obwohl der beta-Treiber eigentlich spir-v unterstuetzen muesste (!?), wofuer eigentlich OpenCL 2.1 Voraussetzung ist (!?)

[SaschaW]

@Sascha: Benötigst du Feedback bezüglich deiner Demos? Unter Win10 x64 + R9 Nano läuft zumindest nicht alles fehlerfrei. Aber sind sonst schön gemacht :)

Edit: Die NV Demos funktionieren mit AMD Hardware nicht, zumindest bei mir.

I know. Ich hab von AMD am Abend vor dem Release noch ne Karte bekommen und hab dann (bis spät in die Nacht) noch ein paar Sachen Demos zum Laufen bringen können.

Aktuell unterstützt der AMD Treibe auch leider nur D16 für den Tiefenpuffer (k.a. warum), d.h. ein paar der Demos haben fieses Z-Fighting.

Aber um den Kram kümmere ich mich dann die nächsten Tage, hoffentlich bekomm ich alles auch auf AMD (und Intel) zum Laufen.

[SaschaW]

Dass man es wegen Talos verschoben hat halte ich aber fuer ausgeschlossen, weil das einfach voelliger Quatsch ist. Das was im Hintergrund kommuniziert wurde, dass man auf bessere treiberseitige Implementierung wartet, ist dagegen wahrscheinlicher. Denn jetzt hat alle Welt Zugriff und interessierte Entwickler moechten es ja schnellstmoeglich implementieren. Zu Software gehoeren immer Tests und das geht halt nicht ohne Treiber, auch wenn man natuerlich schon voerher mit der Implementierung anfangen kann.
Wer im Dezember noch nicht bereit war, ist ja im Uebrigen sehr einfach zu erraten. :rolleyes:

Details darf ich keine Nennen, aber die Verschiebung hat rein gar nix mit Talos Priniciple zu tun. Das war halt so ein Ding das sich zufällig ergeben.

[Ganon]

In die Richtung wurde nichts kommuniziert, obwohl der beta-Treiber eigentlich spir-v unterstuetzen muesste (!?), wofuer eigentlich OpenCL 2.1 Voraussetzung ist (!?)

Die Sache ist halt, dass Vulkan ja auch so einige GPGPU-Fähigkeiten hat und dass NVidia halt momentan die größte Bremse im OpenCL-Bereich ist. NVidia ist halt Marktführer und wenn man schon nicht CUDA benutzt, wird man sicherlich auch nicht OpenCL 2.x nutzen.

Ich kenne jetzt auch nicht den großen Unterschied zwischen Vulkans GPGPU Fähigkeiten und OpenCL 2.1.

Ja, beide fressen im Prinzip SPIR-V, aber die API drum herum ist ja trotzdem noch eine Andere. Nicht ganz so Low Level.

[Brillus]

Und was ist dann der Sinn das Spiel auf Vulcan zu portieren?
Windows XP und Vista werden nicht unterstützt, sondern Windows 7 und neuer, dafür gibt es bereits DX11, was nach und nach schneller geworden ist als DX9. Jetzt betreibt man einen Aufwand, damit das Spiel irgendwann mindestens so schnell läuft wie DX11, vielleicht ergeben sich bessere Effekte. Ist Croteam irgendwie nicht ausgelastet?

Wohl schon vorarbeiten für SS4, was auf der selben/verbesserten Engine von Talos Principle laufen soll.

Und wie die so schön schreiben, die wohlen Tester für dne Vulkan-Path haben.

[M4xw0lf]

I know. Ich hab von AMD am Abend vor dem Release noch ne Karte bekommen und hab dann (bis spät in die Nacht) noch ein paar Sachen Demos zum Laufen bringen können.
Was bekommt man denn da so?

[dildo4u]

anandtech Vulkan Benches

http://abload.de/img/80123pwrsa.png

http://www.anandtech.com/show/10047/quick-look-vulkan-performance-on-the-talos-principle

Gibt Probleme mit 2GB Karten der Vram läuft voll,Entwickler müssen da per Hand nachjustieren.

[Loeschzwerg]

d.h. ein paar der Demos haben fieses Z-Fighting.

Habe ich bemerkt :) (Gears; Instancing...)


hoffentlich bekomm ich alles auch auf AMD (und Intel) zum Laufen.

Was bereitet dir bei Intel noch Schmerzen? Wollte die Tage mein kleines Skylake NUC mit Ubuntu befeuern, aber wenn da nicht viel läuft kommt Debian drauf und ich warte auf nen passenden Treiber via Backports.

[SaschaW]

Was bekommt man denn da so?

Normale Consumer Hardware.

Was bereitet dir bei Intel noch Schmerzen? Wollte die Tage mein kleines Skylake NUC mit Ubuntu befeuern, aber wenn sich das nicht lohnt kommt Debian drauf.

Ich hab einfach noch nicht mit aktuellen Treiber und dem neusten SDK testen können. Kann also sein dass alles geht, glaub ich aber eher nicht ;)

Jetzt so kurz vor Schluß ists dann doch ein bisschen knapp geworden, auf Intel hab ich seit ein paar Wochen nix mehr laufen lassen.

[M4xw0lf]

Normale Consumer Hardware.
Knapp über Rechenschieber oder highend, das meinte ich ^^

[-/\-CruNcher-/\-]

Es wird doch behaupte das die Grundlage auf Mantle (3 Jahre) aufgebaut ist,
somit hat man das Rad nicht neu erfunden und muss von Null anfangen.
Bei DX12 behaupte doch Nvidia das sie sie seit 2009 also 7 jahre daran arbeiten.

Die Roadmap für Windows wohin es geht (IHV Anforderungen) steht seit minimum 2006 Fest (erste öffentliche IHV präsentation auf der WINHec 2006 von Nvidia und ATI zusammen mit Microsoft über die Pläne), seit dem wurde kontinuierlich das WDDM erweitert nach dieser Roadmap hin zu WDDM 2.0.

Also das was du bei Windows 10 nun siehst ist nun schon 9-10 Jahre in Arbeit (Hardware Anpassungen).

Es ist schon erstaunlich was zum Start der NT 6 (era) schon im Prinzip alles auf dem Pappier feststand, wie weit mit NT 6 in die Zukunft gedacht wurde (in der Technischen Umsetzung).

https://www.microsoft.com/whdc/winhec/pres06.mspx

Wurde natürlich viel angepasst vor allem innerhalb der Neuausrichtung auf Mobile in der Zeit wurde aus WDDM 2.0 dann irgendwan WDDM 1.1 WDDM 1.2 (WDDM 2.1) und WDDM 1.3 (WDDM 3.x) und danach das jetzige WDDM 2.0 also (müsste irgendwo bei WDDM 4.0 liegen) man kam scheinbar in Verzug mit den IHVs in der Zeit muss ATI/AMD mit Mantle angefangen haben.

Man kann auch herauslesen worauf ATI sich die Meiste Zeit konzentriert hat und was wir dann als GCN gesehen haben und was Nvdiia momentan am Meisten zu schaffen macht ;)

[samm]

Ja klar, MS hat 2006 schon low level API gepusht - nicht. WDDM 2 und folgende wurden vorgestellt, d.h. unter dem Win Desktop multitasking der GPU unterstützen. DX 10 war das Thema, DX 10.1 wurde geteasert. Abstraktion war ein Thema, sauberer Bruch mit DX 9, und sicher nicht ultradünne Treiber-Layer und möglichst direkte low level Kontrolle.
Augenwischerei um den grossen aktuellen Push Richtung low level zu relativieren. Und mal komplett an Vulkan vorbei.

[Kartenlehrling]

Mit dem neuesten AMD Vulkan Treiber wird meine R9nano jetzt wenigsten erkannt,
jedenfalls funktioniert jetzt das Auslese tool VK-Z , selbst mit der "alten" version VK01.1.

Highlights von … AMD-Vulkan-Radeon-Software-Beta-Feb17

VulkanSDK v1.0.3.1 – Compatibility issues addressed
The Talos Principle – SSAO Fixes

http://www.geeks3d.com/20160217/vk-z-0-1-0-simple-vulkan-api-capabilities-and-extensions-viewer/#comment-85740

[kruemelmonster]

@FM_Jarnis: Now that the Vulkan API is officially released, do you have any plans of supporting Vulkan in 3DMark in the future?Sorry, nothing official to announce. Yet.

:cop: :biggrin:

[Troyan]

nVidia hat die Slides ihres Vulkan Day veröffentlicht:
https://t.co/bIfADoTDtG

[Achill]

Ich schau gerade die Folien von NV durch, bei der Vulkan Overview, Folie 55/56 (http://on-demand.gputechconf.com/gtc/2016/events/vulkanday/Vulkan_Overview.pdf) ist der Vulkan-Support für Fermi durch gestrichen, ist das jetzt der aktuelle Stand?

[Troyan]

Laut nVidia sei die Verbreitung zu gering, um Support zu ermöglichen.

[Locuza]

Ich frage mich, ob sie ihre DX12 Pläne für Fermi damit auch gestrichen haben?
WDDM2.0 haben sie implementiert, auf halber Strecke aufzuhören wäre auch etwas doof.
Für Vulkan wäre es auch nett noch die größere User-Space zu stellen.

[aufkrawall]

Laut Blaire soll es garantiert noch kommen:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10944528&postcount=23

[d2kx]

Valve hat gerade eben den Vulkan Support im Steam Client ausgebaut:

http://steamcommunity.com/groups/SteamClientBeta#announcements/detail/907843576938079481

Weiterhin hat SteamOS einen neuen NVIDIA blob mit Vulkan Support erhalten:

http://steamcommunity.com/groups/steamuniverse/discussions/1/412447613562008582/

Das ist nur der Anfang :smile:

[Nightspider]

Valve scheint Vulkan gut pushen zu wollen.

Vielleicht kommt Half Life 3 nur mit Vulkan Support und komplett ohne DX12. :D

[kruemelmonster]

WDDM2.0 haben sie implementiert, auf halber Strecke aufzuhören wäre auch etwas doof.

Wenn ich das richtig verstanden hab war WDDM 2.0 für Fermi nötig um parallel zu Kepler/Maxwell in einem System betrieben zu werden. Hätte Fermi kein 2.0 bekommen hätte der Treiber für alle NV GPUs auf 1.3 runtergeschaltet und damit DX12 verhindert.

[Kartenlehrling]

Steam Overlay

Added preliminary support for Vulkan games

Was kann man den da alles mit machen,
der FPS-Meter ist so klein das er als Pixelfehler durchgehen könnte :)

[N0Thing]

Valve scheint Vulkan gut pushen zu wollen.

Vielleicht kommt Half Life 3 nur mit Vulkan Support und komplett ohne DX12. :D

Wäre nur naheliegend. Valve möchte möglichst unabhängig von Microsoft sein und eine Entwicklung sowohl für DX12 als auch für Vulkan wäre relativ sinnlos.

Wenn ich das richtig verstanden hab war WDDM 2.0 für Fermi nötig um parallel zu Kepler/Maxwell in einem System betrieben zu werden. Hätte Fermi kein 2.0 bekommen hätte der Treiber für alle NV GPUs auf 1.3 runtergeschaltet und damit DX12 verhindert.

Da frage ich mich: Gibt es mehr Systeme mit Fermi- und Kepler-GPUs als reine Fermi-Systeme? Ich mein, wie wahrscheinlich ist es denn, dass man neben einer Kepler/Maxwell-GPU auch noch nen Fermi im Rechner hat und das in einem Zocker-PC. Scheint mir arg unwahrscheinlich. :confused:

[kruemelmonster]

Gibt ja nicht nur Zockersysteme sondern noch den ganzen Quadro (samt NVS Sparte) und Tesla Bereich, die paar Leute mit ner 460 als Physikpumpe liegen da denke ich eher nicht im Fokus.

[SaschaW]

Valve scheint Vulkan gut pushen zu wollen.

Vielleicht kommt Half Life 3 nur mit Vulkan Support und komplett ohne DX12. :D

Valve hat großes Interesse an Vulkan, und hat u.a. das von LunarG entwickelte SDK (und damit quasi die Grundlage für alles was am Launchtag da war, auch mein Kram) gesponsort ;)

[Eidolon]

Also das HL3 (wenn es denn jemals kommt) ohne DX12 kommt, sollte eigentlich jedem jetzt schon klar sein. ;-)

[S940]

Valve scheint Vulkan gut pushen zu wollen.
Nur logisch, unter SteamOS gibts kein DX12 ;)

[iuno]

Dass valve pushen wird war ja voellig klar. Mich wundert nur etwas, dass sie sich, die erste oeffentliche Beta nehmen liessen. Von source2/dota gab es ja schon recht frueh eine lauffaehige Demo.
Ich hoffe, dass sie da nicht geizen, sondern einfach die Strategie geaendert haben. SteamOS hat schelchte Presse gemacht, und Vulkan soll es fuer Valve richten. Sie wollen sicher keine Vulkan Version veroeffentlichen, die aktuell noch langsamer ist.
Valve soll von mir aus einen Batzen Geld in die Hand nehmen, das richtig machen und dann auch CS:GO umstellen. Dann haetten in der Theorie (falls HW halbwegs aktuell) einfach schon mal 1-1,5 Mio aktive Spieler (http://store.steampowered.com/stats/) "ploetzlich" Vulkan.

[just4FunTA]

ja also ein vulkan das schlechter läuft als dx können sie sich gleich sparen.. Und mit dem Zeit lassen hat valve ja keine Probleme. ;)

[Lurtz]

ja also ein vulkan das schlechter läuft als dx können sie sich gleich sparen.. Und mit dem Zeit lassen hat valve ja keine Probleme. ;)
Lief Dota2 mit dem offenen AMD-Treiber unter Linux nicht schon in OpenGL besser als mit DX unter Windows?

[Ganon]

Lief Dota2 mit dem offenen AMD-Treiber unter Linux nicht schon in OpenGL besser als mit DX unter Windows?

Leicht schneller / gleichschnell würde ich sagen:

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

Müsste man halt mit aktuellem Kernel und Mesa noch mal testen. Da hat sich auch einiges getan. Muss man halt nur optimieren und nicht irgendeine Wrapper-Software nutzen wie Valve es auch gerne tut bzw. getan hat.

[iuno]

Das ist halt nicht repraesentativ.
Passend dazu gibt es einen recht frischen Test von Michael/Phoronix: https://phoronix.com/scan.php?page=news_item&px=RadeonSI-Blob-Dota-2-GL

Da ist der offene Stack (teilweise sehr deutlich) vor dem Catalyst, vor allem bei niedrigeren Aufloesungen. Bezeichnend ist hier mal wieder, dass die Fury mit Catalyst von 1280x1024 bis 3840x2160 gerade mal um die 5% schwankt :rolleyes: Ein Vergleich mit Windows ist aber nicht dabei.

Ich denke auch, dass Valve sich bei der Source2 einfach mit DX keine Muehe mehr macht. Was dann hier noch mit Vulkan passiert wird auf jeden Fall Spannend.

[Ganon]

Ich denke auch, dass Valve sich bei der Source2 einfach mit DX keine Muehe mehr macht.

Bei OpenGL noch weniger:

https://github.com/ValveSoftware/ToGL

[Stebs]

Bei OpenGL noch weniger:

https://github.com/ValveSoftware/ToGLAFAIR, hat man für Source 2 nur anfänglich ToGL genutzt und später dann "nativer" umgesetzt, ist aber eigentlich "hörensagen", evtl. weiß ja einer genaueres?

[iuno]

Das war einmal. Natuerlich ohne genaueres zu wissen, glaube ich nicht, dass auch nur sowas in der Art noch in der Source 2 zum Einsatz kam. ToGL geht auch nur mit DX9, Dota Reborn mit Source 2 nutzt DX11.
"weniger" kann auch schonmal nicht sein, denn damit toGL funktioniert, muessen sie sich ja erstmal mit DX Muehe gemacht haben ;) Mit ToGL wuerde man imho die Performance auch nicht so hinbekommen wie es offenbar der Fall ist

davon ab braucht man eigentlich mit Gallium-nine gar kein toGL mehr.

[Guest83]

Valve scheint Vulkan gut pushen zu wollen.
Scheint? Das ganze Vulkan-Projekt wurde bei einem Treffen gestartet zu dem Valve geladen hat. Sie finanzieren die SDK-Entwicklung (LunarG) und programmierten letztes Jahr sogar einen experimentellen Intel-Grafiktreiber für Vulkan um Source 2 zu portieren.


Vielleicht kommt Half Life 3 nur mit Vulkan Support und komplett ohne DX12. :D
Hab letztes Jahr einen Source 2-Programmierer über Windows und Vulkan gefragt und folgende Antwort bekommen: It’s too early to say definitively what we’ll use on Windows long term. Obviously, a Vulkan-only approach would be preferable since it means supporting fewer rendering backends in Source 2.

[iuno]

Der Intel Treiber kam ebenfalls von LunarG, von Valve bezahlt, ja, aber nicht entwickelt.

[aufkrawall]

Lief Dota2 mit dem offenen AMD-Treiber unter Linux nicht schon in OpenGL besser als mit DX unter Windows?
Unter Windows läuft DX9 bei Dota 2 komischerweise auch schneller als DX11.
Man sollte die Source-Engine nicht überbewerten, von hardwarefordernden AAA-Produktionen wie Assassin's Creed oder Mirror's Edge ist Valve doch Welten entfernt. imho können die dabei gar nicht mehr mitreden und bei VR scheinen sie auch links und rechts von UE und Cryengine/Amazon überholt zu werden oder wurden es schon längst unaufholbar.

[iuno]

lt. wem? hier (http://www.golem.de/news/dota-2-reborn-beta-valves-source-2-engine-unterstuetzt-nun-directx-11-1506-114769.html) laeuft DX11 z.B. schneller bei besserer Optik.

Klar steht Valve technisch schlecht da, wenn man mit DICE oder Crytek vergleicht, aber was ist das auch fuer ein Vergleich. Valve macht fast nur noch Steam und die Entwicklung ist nur noch ein kleines Nebenprojekt. Trotzdem haben sie einfach zigfach mehr Spieler.

[aufkrawall]

lt. wem? hier (http://www.golem.de/news/dota-2-reborn-beta-valves-source-2-engine-unterstuetzt-nun-directx-11-1506-114769.html) laeuft DX11 z.B. schneller bei besserer Optik.

Edit:
Moment.


Klar steht Valve technisch schlecht da, wenn man mit DICE oder Crytek vergleicht, aber was ist das auch fuer ein Vergleich. Valve macht fast nur noch Steam und die Entwicklung ist nur noch ein kleines Nebenprojekt. Trotzdem haben sie einfach zigfach mehr Spieler.
Die Spiele laufen alle mit Gurk-Hardware. imho eher ein klägliches Trotz-Signal, das gegen MS zielt.
Vulkan wird Spielern dieser Spiele nichts bringen, dessen sollte man sich bewusst sein.

[Guest83]

und bei VR scheinen sie auch links und rechts von UE und Cryengine/Amazon überholt zu werden oder wurden es schon längst unaufholbar.
Soso, wieviele Amazon-Engine-VR-Spiele gibt es denn? Die allermeisten werden mit Unity gemacht, was du überhaupt nicht aufgezählt hast. Die ist momentan führend in der VR-Entwicklercommunity, mit UE4 (mit großem Abstand) auf Platz 2.

Die Aperture Science Demo mit Source 2 gilt übrigens noch immer als die optisch beeindruckendste VR-Kulisse in Sachen Bildqualität. Macht vielleicht auf Videos nicht soviel her, das ruhige Bild durch massives Filtern (8xMSAA, Forward-Renderer sei dank) erzeugt in einem VR-Headset, wo die Kamera (der Kopf) permanent in Bewegung ist, einen besonders hohen Realismusgrad.

[aufkrawall]

lt. wem? hier (http://www.golem.de/news/dota-2-reborn-beta-valves-source-2-engine-unterstuetzt-nun-directx-11-1506-114769.html) laeuft DX11 z.B. schneller bei besserer Optik.

Die Seite von Valve, auf die sich Marc dort bezieht, erwähnt überhaupt nicht, dass mit DX11 die Grafik besser wäre. In der Einleitung des Golem-Artikels wird aber der Eindruck erweckt.
Es gibt dort überhaupt keinen Beweis, dass mit DX11 die Grafik besser wäre. Mir ist damals auch nichts aufgefallen, bei meinem Test im GPU-Limit war DX11 langsamer als DX9:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10940723&postcount=2541
Du kannst es auch einfach selber ausprobieren.

Soso, wieviele Amazon-Engine-VR-Spiele gibt es denn?

Die Frage sollte zum momentan Zeitpunkt eher sein, wie viele kommen werden.


Die allermeisten werden mit Unity gemacht, was du überhaupt nicht aufgezählt hast. Die ist momentan führend in der VR-Entwicklercommunity, mit UE4 (mit großem Abstand) auf Platz 2.

Meinetwegen. Das liegt aber auch daran, dass der Markt noch nicht entsprechend für AAA etabliert ist. Wenn das geschieht, kann Unity auch ganz schnell wieder auf Maße schrumpfen, die man sich als Spieler für diese Engine wünschen sollte.

[iuno]

Die Spiele laufen alle mit Gurk-Hardware. imho eher ein klägliches Trotz-Signal, das gegen MS zielt.
Vulkan wird Spielern dieser Spiele nichts bringen, dessen sollte man sich bewusst sein.
Und? Gerade bei schwacher HW und APUs koennte es schon was bringen. Es soll aber natuerlich vor allem Valve was bringen, um von MS unabhaengiger zu werden. Natuerlich ist das alles eine grosse "Trotz"-Reaktion, was aber auch voellig legitim ist. Valve hat die Einfuehrung von Windows 8 schon kritisch gesehen und jetzt verkauft MS demnaechst Spiele exklusiv im eigenen Store.

Und falls es am Ende z.B. noch andere Entwickler anspornen kann, kann das nur gut fuer uns sein.

[aufkrawall]

Und? Gerade bei schwacher HW und APUs koennte es schon was bringen.

Warum, sind/wären die Spiele nennenswert CPU-limitiert mit DX11? Ich denke nein.

[-/\-CruNcher-/\-]

Leicht schneller / gleichschnell würde ich sagen:

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

Müsste man halt mit aktuellem Kernel und Mesa noch mal testen. Da hat sich auch einiges getan. Muss man halt nur optimieren und nicht irgendeine Wrapper-Software nutzen wie Valve es auch gerne tut bzw. getan hat.

Soll das ein schlechter scherz sein die Test Methodik kannst du knicken die Ergebnise sind ja mal rein garnichts wert.

[Botcruscher]

VR muss dieses Jahr erst mal aus dem Alphastadium in die nutzbare beta schaffen. Mal sehen was vom Hype dann noch im Massenmarkt übrig bleibt. Bei einer Preisgestaltung jenseits der 500€ wird da überhaupt nichts passieren.

[kruemelmonster]

AIDA Version: 5.60.3768 beta (Feb 19, 2016)

Release notes:

new page: Display / Vulkan
Benchmark Results Manager / Copy and Copy All in right-click menu
extended reference OpenGL Extensions list (for Vulkan)
Intel Processor Number detection for Atom x5-Z8330
Intel Processor Number detection for Xeon D-1571
sensor support for Dell SMI of OptiPlex 3040

http://www.aida64.com/downloads/latesta64xebeta

@Botcrusher: Falscher Thread?

[Botcruscher]

Nö. Die Aussage war ja Valve wäre technisch total hinten dran und Vulkan würde da quasi eh nichts mehr retten. PS: Dazu der Vergleich mit der Gurk-Hardware als Valve Zielgruppe. Eben diese Zielgruppe wird am meisten profitieren. Das hat AMD schon mit Mantle gezeigt. Im oberen Leistungsbereich wird eher nichts ankommen.

[aufkrawall]

Hast du Dota 2 überhaupt jemals gespielt? Dir ist schon klar, in welchem Bereich sich die fps dort bereits mit DX9 bewegen? Mit einem guten DX11 Renderer läuft das auf jedem Taschenrechner dreistellig...

[DevilX]

Sollte es hier nich um die Vulkan API gehen?
Irgendwie wird das ganz schon OT

[Botcruscher]

Mit einem guten DX11 Renderer läuft das auf jedem Taschenrechner dreistellig...
Mach 4K an du Witzbold.

[aufkrawall]

Erst soll Vulkan für die Valve-Spiele etwas mit langsamer Hardware bringen, und jetzt argumentierst du, man solle in 4k spielen?
Sonst noch in Kontakt mit der Realität?

[Botcruscher]

Das Dota2 nicht ordentlich skaliert und Leistung verlangt kannst du vergessen. Wenn ein Taschenrechner für HD im dreistelligen Bereich reichen soll dann sollte ja wohl mit ordentlicher Hardware die lächerliche vierfache Auflösung drin sein. Im Teamfight ist dann Standbild mit dem Taschenrechner.
Das schwächere Hardware mehr am CPU limit liegt und damit eher profitiert erübrigt sich.

[aufkrawall]

Das Dota2 nicht ordentlich skaliert und Leistung verlangt kannst du vergessen.

Ich verstehe diesen Satz nicht.


Wenn ein Taschenrechner für HD im dreistelligen Bereich reichen soll dann sollte ja wohl mit ordentlicher Hardware die lächerliche vierfache Auflösung drin sein. Im Teamfight ist dann Standbild mit dem Taschenrechner.

Das liegt aber an der GPU und nicht an der CPU, wenn das Spiel nicht scheiße programmiert ist. Gegen beschissene Programmierung bringt Vulkan gar nichts, das Gegenteil dürfte der Fall sein.

Valve bietet DX11 ja nicht mal offiziell für Dota an, obwohl die API schon zig Jahre alt ist. HotS krebst auch noch mit DX9 rum.
Und jetzt auf einmal soll es Vulkan für genau diese Spiele bringen? Wohl kaum.


Das schwächere Hardware mehr am CPU limit liegt und damit eher profitiert erübrigt sich.
Du solltest dir mal bewusst machen, dass Vulkan überhaupt nicht auf Pre-GCN und -Kepler läuft.
In Notebooks mit brauchbarer Intel-CPU sitzen häufig eben nicht brachial schnelle GPUs, da sind häufig die CPUs unnötig fett für die GPU-Leistung.

[Lurtz]

Die aktuelle Steam-Beta hat zwei Fixes für Vulkan:
Steam Overlay
Added preliminary support for Vulkan games
Linux
Added libvulkan, the Vulkan ICD loader, to the Steam Runtime

[SaschaW]

Hab die ungültigen Reports jetzt aus der Datenbank geschmissen (Fermi), die Links zu den Reports haben im Netz leider weite Kreise gezogen :/

Außerdem hab ich aus "Queues" "Queue Families" gemacht. Das ist korrekter, und sorgt hoffentlich nicht mehr für so viel Verwirrung.

[Kartenlehrling]

wird der Driver nicht auch falsch ausgelesen ?

0.0.1
The Vuklan API version is not correct, it should be 1.0.3

[Troyan]

Außerdem hab ich aus "Queues" "Queue Families" gemacht. Das ist korrekter, und sorgt hoffentlich nicht mehr für so viel Verwirrung.

Für was steht eigentlich "Queue Count"? Habe bei Khronos nichts dazu gefunden.

[SaschaW]

wird der Driver nicht auch falsch ausgelesen ?


The Vuklan API version is not correct, it should be 1.0.3

Du meinst bei AMD und INTEL? Ich gebe aus was mir der Treiber liefert, und das ist bei denen nach Vulkan Konvention umgewandelt 0.0.1. Vermutlich füllt man hier die DeviceProperties noch nicht korrekt, war bei NV mit Pre-Release Treibern auch so. Dort hat man jetzt aber sowohl unter Windows, Linux als auch Android die korrekten Versionsnummern drin.

[SaschaW]

Für was steht eigentlich "Queue Count"? Habe bei Khronos nichts dazu gefunden.

Aus den Specs (https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkGetPhysicalDeviceQueueFamilyProperties.html) :

queueCount contains the number of individual queues within the specified queue family. Queues within a single family are considered identical from a feature support perspective and are directly compatible with one another.

Deshalb hab ich das von "Queues" nach "Queue Families" geändert. In einigen Foren meinten die Leute dass es z.B. bei NVIDIA nur eine Queue gibt und man nix synchron machen kann.

Das stimmt natürlich nicht. NVIDIA hat eine Queue Familie in der man (Queue Count) bis zu 16 Queues anlegen kann. Queues aus einer Familie sind zueinander kompatibel.

[iuno]

early talos@linux vulkan vs ogl benchmarks:
http://www.phoronix.com/scan.php?page=article&item=vulkan-gl-talos&num=2

anders als unter windows ist ogl hier derzeit durchgaengig schneller.

[Troyan]

Vielen Dank SashaW. Macht die Sache verständlicher.

[kruemelmonster]

@Sascha:

Ich hab mal interessehalber den NV Vulkan Treiber auf einer GTX 470 installiert, war nichtmal ein Mod erforderlich, Fermi wird offiziell unterstützt.
Die neueste AIDA64 Beta sowie VK-Z von Geeks3D liefern auf den ersten Blick die gleichen Daten wie dein VulkanCapsViewer, nur gibt dieser beim Start "Could not create a Vulkan device!" aus.
Beim Vergleich zwischen GF100 und GK104 mit deinem Tool fällt auf das Fermi lediglich ein einzelnes Feature fehlt, und zwar "residencyStandard3DBlockShape", der Rest sieht identisch aus.

Ich hoffe mal weiter auf Vulkan für Fermi, immerhin haben die 400er & 500er Karten auf Steam noch knapp 10% Marktanteil.

[SaschaW]

@Sascha:

Ich hab mal interessehalber den NV Vulkan Treiber auf einer GTX 470 installiert, war nichtmal ein Mod erforderlich, Fermi wird offiziell unterstützt.
Die neueste AIDA64 Beta sowie VK-Z von Geeks3D liefern auf den ersten Blick die gleichen Daten wie dein VulkanCapsViewer, nur gibt dieser beim Start "Could not create a Vulkan device!" aus.
Beim Vergleich zwischen GF100 und GK104 mit deinem Tool fällt auf das Fermi lediglich ein einzelnes Feature fehlt, und zwar "residencyStandard3DBlockShape", der Rest sieht identisch aus.

Ich hoffe mal weiter auf Vulkan für Fermi, immerhin haben die 400er & 500er Karten auf Steam noch knapp 10% Marktanteil.

Unterstützt wird Vulkan erst dann wenn man ein gültiges VkDevice erstellen kann, welches die Sicht der API auf die Hardware darstellt. Und das geht bei Fermi nicht. Die Daten die man davor bekommt (also dass was auch AIDA64 und VK-Z anzeigen) basieren auf der Vulkan Instanz, und dass man da Daten bekommt liegt vermutlich an der GL/VK-Interop bei NVIDIA.

2015 hat NVIDIA zwar Vulkan auch für Fermi angekündigt (Vulkan Support für FERMI war mal angekündigt (http://on-demand.gputechconf.com/siggraph/2015/presentation/SIG1501-Piers-Daniell.pdf), aber das hat momentan wohl zu wenig Priorität.

[z3ck3]

Ich werd wohl meinen gesamten PC ende des Jahres in Rente schicken und nur noch als Arbeitsmaschine nutzen. Dann gibts ne AMD Grafikkarte samt Zen (wenn sie es nicht verkacken), und mich interessiert auch nimmer das Nvidia meine GTX 570 so stiefmütterlich behandelt. :D

Leider scheint AMD ja GCN 1.0 und 1.1 ebenso zu vernachlässigen (obwohl sie immer noch GPUs mit der Technologie verhökern R7 370 und R7 360, so wie die APUs Kaveri und Kabini). Und mit Linux Treibern kommen sie ja scheinbar auch nicht hinter her. Scheint wirklich so als wenn AMD ein ernsthaftes Resourcen Problem hat. Da muss Zen und GCN 2 ja der Hammer werden. Wenn nicht, weine ich. ^^

[-/\-CruNcher-/\-]

early talos@linux vulkan vs ogl benchmarks:
http://www.phoronix.com/scan.php?page=article&item=vulkan-gl-talos&num=2

anders als unter windows ist ogl hier derzeit durchgaengig schneller.

Auch wenn es noch sehr Früh ist gut sieht das nicht aus CroTeam sind wahrlich keine Anfänger.

Da kann man gespannt sein wie die GCN Ergebnise aussehen werden.

[iuno]

@z3ck3: Benutzt du ueberhaupt Linux? Ich wuesste nicht, was es unter Windows mit den Treibern fuer ein Problem gaebe mit Sea Islands (1.1).
lt. bridgman soll zumindest der vulkan userspace Treiber bald kommen. Ich werde dann mal schauen, wie es mit CI + amdgpu + vulkan ausschaut.

The Linux driver isn't being delayed *that* much :)

Ist halt schade, dass das noch unter verschlossenen Tueren stattfinden muss und nicht direkt etwa Teil von Mesa wird. Aber die haben einfach keine Kohle mehr. bridgman, alex deucher usw. koennen auch keine konkrete Angaben machen. Das kleine Team scheint mit der Offenlegung einfach ueberfordert, teils kann es ja auch rechtliche Probleme geben. Kurzfristig und wirtschaftlich gesehen ist es ganz klar, dass sie sich auf Windows konzentrieren.
Ich verstehe aber auch die Community nicht. Fuer Nouveau gibt es viele Bestrebungen, die Entwickler stuerzen sich geradezu in die Arbeit, bei AMD sieht das anders aus, obwohl die schon lange viel offener damit umgehen. Wobei ich auch sagen muss, dass ich bei der aktuellen Situation keine Lust haette, mich einzubringen. AMD muesste es halt endlich mal schaffen, reinen Tisch zu machen, klar zu sagen wo es langgeht und dann den Kram rausruecken.

@Sascha: haeltst du als Option eine OpenGL (4.5) Implementierung auf Vulkan eigentlich fuer realistisch? Gerade z.B. das Mesa Projekt koennte davon stark profitieren, sollte das funktionieren. Der Vulkan Treiber als duennes Layer fuer jede Architektur mit weniger Pflegeaufwand und dann on top die OGL Implementierung, die auf allen funktioniert. Das koennte doch einen Haufen Arbeit ersparen.

[z3ck3]

@Ino: Ja, ich benutze Linux, wenn auch auf meinem Hauptrechner (noch) nur in ner VM. Das spielt aber keine Rolle bei der Feststellung das AMD keinen Vulcan Treiber für Linux gebracht hat, und vermutlich GCN 1.0 und 1.1 (unter Linux) nicht (oder nur eingeschränkt) unterstützen wird wenn ich das richtig verstanden habe. Ich habe das nicht genau verfolgt, da ich davon weniger betroffen bin. Bei mir ist es NV die mir wohl was neues verkaufen wollen. ^^

[SaschaW]

@Sascha: haeltst du als Option eine OpenGL (4.5) Implementierung auf Vulkan eigentlich fuer realistisch? Gerade z.B. das Mesa Projekt koennte davon stark profitieren, sollte das funktionieren. Der Vulkan Treiber als duennes Layer fuer jede Architektur mit weniger Pflegeaufwand und dann on top die OGL Implementierung, die auf allen funktioniert. Das koennte doch einen Haufen Arbeit ersparen.

Halte ich für unrealistisch. Wurde auch beim öffentlichen Vulkan Webinar vorgestern angesprochen. Wenn man eine OpenGL-Implementierung auf Vulkan aufsetzen will muss man ja quasi alles machen was auch ein OpenGL-Treiber macht, und das wäre sehr aufwendig.

[iuno]

du machst das falsch herum, in die VM gehoert Windows *scnr*

1.0 kannst du glaube ich vergessen, 1.1 sehe ich dagegen ziemlich sicher.
bridgman hat glaube ich mal geschrieben, dass SI (1.0) etwa gcn core + NI (6000er Serie) uncore ist, deshalb waere der Umbau da deutlich aufwendiger. Er meint aber immer, dass sie noch versuchen, es umzusetzen.
bridgman ist imho immer etwas optimistisch, aber vielleicht ist das vergleichbar mit Nvidias moeglicher Fermi Unterstuetzung.
Generell ist es natuerlich schade, dass noch kein Linux Treiber da ist, das stimmt natuerlich. Allerdings sieht es unter Windows ja auch nicht viel besser aus. Der Treiber hat noch nicht mal den Konformitaetstest bestanden

Wenn man eine OpenGL-Implementierung auf Vulkan aufsetzen will muss man ja quasi alles machen was auch ein OpenGL-Treiber macht, und das wäre sehr aufwendig.
Genau, aber eben nur ein mal. und nicht fuer radeonsi, i965, nvc0, nve0, nv110, ...

[Ganon]

Hier hat mal einer der Mesa-Entwickler darüber sinniert OpenGL auf Vulkan aufzusetzen:

https://lists.freedesktop.org/archives/mesa-dev/2016-February/107937.html

tl;dr: Wäre möglich, aber schwer mit guter Performance hinzubekommen. Hat bisher keiner ernsthaftes Interesse daran.

Wie dem Thread zu entnehmen ist, ist die Ideensammlung bei Mesa gerade mehr in die Richtung wie man Gallium3D ähnlich Vulkan-Code zwischen den einzelnen Treibern wiederverwenden kann.

[Ganon]

@iuno

Nicht zu vergessen, dass "OpenSource AMD" immer wieder durch die hausinterne Rechtsabteilung gebremst wird, was schnelle Veröffentlichungen halt unmöglich macht.

[iuno]

war wohl etwas zu einfach gedacht. Klingt in der Theorie halt toll, die Umsetzung und Machbarkeit steht natuerlich auf einem ganz anderen Blatt. Aber vom Tisch scheint das nicht zu sein, es geht ja da dann mehr um die Implementierung von Vulkan an sich. Sollte natuerlich auch Prioritaet haben, der Gedankengang "OGL on Vulkan" ist ja schon einen Schritt weiter.

Ja, das ist durchaus ein Punkt, habe ich auch kurz unter "rechtliche Probleme" zusammengefasst. Da bleibt es interessant, was passiert, da der Vulkan user space fuer Linux ja os werden soll, aber sie haben auch gesagt, dass es kuenftig dieselbe Codebasis fuer Linux und Windows gibt.

[Kriton]

Valve bietet DX11 ja nicht mal offiziell für Dota an, obwohl die API schon zig Jahre alt ist. HotS krebst auch noch mit DX9 rum.

Blizzard war noch nie technisch auch nur ansatzweise führend und meistens üblicherweise deutlich zurück.

[][immy]

Blizzard war noch nie technisch auch nur ansatzweise führend und meistens üblicherweise deutlich zurück.
Das liegt eher daran, das man möglichst viele Kunden gewinnen will und sich nicht nur auf die <10% stürzen, die top-hardware haben.
Klar kann DX10/11 haben inzwischen deutlich mehr (Unterstützung) allerdings musste man bis vor kurzem auch noch Windows XP bedienen, was jetzt endlich mal weg fäll.t
Bis blizzard wirklich auf DX12 umsteigt (an Vulkan denke ich noch nicht mal) wird es noch ne weile dauern. Blizzard hat ja auch OpenGL nur sehr stiefmütterlich in der Vergangenheit behandelt.

[Kriton]

Das war kein Vorwurf an Blizzard, sondern nur der Hinweis, dass Blizzard kein Hinweis darauf ist, inwieweit sich eine neue API generell durchsetzt.

[z3ck3]

@iuno: Auch wenn das hier OT ist, Ja mich stört das auch. Ich mag Windows, aber ich brauche es eigentlich nur noch für Photoshop. Ich arbeite meistens in der VM (Netbeans, Terminal). Gäbe es eine Möglichkeit einer VM eine dedizierte Grafikakrte zuzuweisen (z.b. eine R7 260), und die Bildschirmausgabe dann abzufangen und eben nicht von der Grafikkarte sondern vom Host ausgeben zu lassen, dann wäre das bei mir anders herum. Ich habe sogar schon ernsthaft darüber nachgedacht die neue Workstation mit zusätzlichem Monitor und Eingabegeräten auszustatten um dann zwei Systeme über die gleiche Maschine zu realisieren (kam ich drauf durch das Linustech 7 Gamers 1 CPU). Jedenfalls ist mir Photoshop und co ohne Hardware Beschleunigung zu träge. Auch gibt es das eine oder andere Windows Only Game das ich gerne mal spiele. Dualboot ist für mich keine Option und irgendwelche KVM Lösungen auch eher weniger. Am liebsten wäre mir eine Seemless Integration der VM inkl. Hardwarebeschleunigung in den Host. Wäre das möglich, wäre ich überglücklich. XD (oder noch lieber wäre mir eine native Creative Cloud unter Linux)

[iuno]

Ganz so geht es nicht, aber fast ;)
Du kannst die Grafikkarte zur VM 'durchreichen', dein System muss dafuer VT-d (Intel) bzw. VI (AMD) unterstuetzen. Fuer den Host kann man dann die iGPU oder eine zweite, kleine GK benutzen.
Dann muss die Bildausgabe aber auch ueber die GK gemacht werden. Hat dein Monitor nur einen Eingang oder wieso stellt das sonst fuer dich eine Huerde dar?
Zusaetzlicher Monitor/Eingabegeraete sind dafuer auch nicht noetig. Du kannst einzelne USB Geraete oder auch einen ganzen USB Controller durchreichen, dann hast du auch direkten Input beim Gast. Wenn er wieder heruntergefahren wird, gehen die Geraete wieder an den Host.
Beim Host "fehlt" die GK dann halt, das taugt also nur wenn man sie dort nicht braucht. Zur Laufzeit zu switchen ist mindestens problematisch. Mit reboot wuerde es gehen, aber dann kann man auch gleich dual boot machen.

sorry fuer ot :weg:

[z3ck3]

Ja ist mir bekannt. Rumswitchen ist eher blöd weil 2 Monitore. Da ist rüber rollen schneller. Darum wäre eine Umleitung des Framebuffers von der dGPU des Guests inkl. Seemless Integration in den Host die fast perfekte Lösung. Fast darum, weil die Tastenkombis von Photoshop und Linux sich überschneiden, so das auch das nicht unproblematisch ist. Muss also eigentlich eh dedizierte Eingabegeräte haben. Linux als Guest ist einfach sorgenfreier. Ich werde mich damit dann noch mal beschäftigen wenn ich mir ne neue Workstation kaufe. Vielleicht behalte ich auch den PC hier komplett für Linux und bau mir noch ne zweite Maschine für Windows. Wie auch immer. OT, schluss jetzt :D

[Ganon]

Auch wenn OT und "schluss jetzt"... Intel unterstützt mit XenGT bzw. KVMGT das durchreichen der GPU per Timesharing. Ich weiß nicht wie der Stand beim Windows-Support ist, ist aber zumindest geplant.

Ich glaube AMD und NVidia arbeiten an ähnlichem Kram.

[d2kx]

Samsung hat gerade auf dem Galaxy S7 Event Vulkan-Support für das S7 angekündigt.

Tim Sweeney von Epic Games war auf der Bühne und hat eine Unreal Engine 4 Demo auf dem Samsung-Phone vorgeführt. Er sprach von "we can render scenes 4x faster than with OpenGL".

Partnerschaft zwischen Samsung, Oculus und Epic Games.

FnKu7MLB7vQ

lIdNoSB69PI

[dargo]

Ich bin schon sehr auf die neuen Only DX12/Vulkan Games gespannt. Ich denke mit den neuen APIs sollte sich im Bereich Physik einiges ändern. Schön wäre auch wenn viele Debris zb. bei Explosionen liegen bleiben würden.

[Brillus]

Samsung hat gerade auf dem Galaxy S7 Event Vulkan-Support für das S7 angekündigt.

Tim Sweeney von Epic Games war auf der Bühne und hat eine Unreal Engine 4 Demo auf dem Samsung-Phone vorgeführt. Er sprach von "we can render scenes 4x faster than with OpenGL".

https://pbs.twimg.com/media/Cbwm7ElWEAEbNRj.jpg

Partnerschaft zwischen Samsung, Oculus und Epic Games.

http://youtu.be/OKtv-iJPEzQ

Sieht wirklich nice aus, vor allem wenn man bedenkt das soll auf Handy laufen.

[Achill]

Samsung hat gerade auf dem Galaxy S7 Event Vulkan-Support für das S7 angekündigt.

Tim Sweeney von Epic Games war auf der Bühne und hat eine Unreal Engine 4 Demo auf dem Samsung-Phone vorgeführt. Er sprach von "we can render scenes 4x faster than with OpenGL".

https://pbs.twimg.com/media/Cbwm7ElWEAEbNRj.jpg

Partnerschaft zwischen Samsung, Oculus und Epic Games.



Auch ein sehr schönes Demo, hier gibt es dies ohne den Interview-Part mit etwas mehr 'bling-bling' ... ;)

[ YT]lIdNoSB69PI[/YT ]

Ninja'd by d2kx xD

[Locuza]

Ich bin schon sehr auf die neuen Only DX12/Vulkan Games gespannt. Ich denke mit den neuen APIs sollte sich im Bereich Physik einiges ändern. Schön wäre auch wenn viele Debris zb. bei Explosionen liegen bleiben würden.
Direkt durch die APIs selber erwarte ich dort nicht viel.

[-/\-CruNcher-/\-]

ASTC rules für niedrige bitraten wünschte DX 12 hätte support dafür gebracht Nativ in Hardware :)

[z3ck3]

Vielleicht kommt ja ein Engine Entwickler mal langsam auf die Idee die iGPU oder ein weitere dGPU für die Physik Berechnungen zu nutzen. Mitlerweile sollten über 90% aller Gaming PC Besitzer eine CPU, eine iGPU und mindestens eine dGPU haben. Eine wesentlich bessere KI könnte man auch langsam mal gebrauchen. Bei der Grafikqualität fehlt mir seit langem nur noch eine wesentlich bessere Beleuchtung (RT: realistischere Spiegelungen, Schatten und Transparenzen).

Apropos RT, wird sich da vielleicht mal etwas ändern mit Vulcan?

[iuno]

Interessant, vor allem da epic selbst afaik noch nichts zu Vulkan bzw. einem Zeitplan gesagt hat.
Sicher koennte durch freiwerdende Ressourcen auch etwas mehr in Physik investiert werden, aber an einen Prioritaetswechsel glaube ich nicht. Grafik zieht einfach noch mehr und ist auch naheliegender.

Wenn die ungenutzte iGPU wirklich mal z.B. fuer Physik oder Post Processing genutzt wird, um CPU/GPU zu entlasten, koennte das schon grosse Auswirkungen haben. Daran glaube ich aber nicht nur aus Komplexitaetsgruenden (Software) erstmal nicht. Problematisch ist, dass High-End/Enthusiast Kaeufer mit 2011-Plattform oder AMD FX damit im Nachteil waeren. Imho sollte erstmal generell mehr Multithreading genutzt werden.

edit: falls das zuvor besprochene Thema weiterhin interessant ist, koennte es hier weitergehen: Spielen "unter Linux" mit virtueller Windows-Installation (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10950398)

[aufkrawall]

Steam-Overlay unterstützt nun auch Vulkan:
http://store.steampowered.com/news/?feed=steam_client

Und Treiber-Unterstützung für Windows ist bei AMD & NV nun auch mit den normalen Consumer-Treibern vorhanden.
Falls die in den nächsten Monaten über Windows Update ausgerollt werden, würde Vulkan schnell eine ziemlich hohe Verbreitung erfahren.

[kruemelmonster]

Wie kommt es eigentlich dass bis heute keine einzige AMD-Karte offiziell Vulkan (https://www.khronos.org/conformance/adopters/conformant-products#vulkan)-kompatibel (https://www.khronos.org/conformance/adopters/conformant-companies#vulkan) ist?
Einerseits hat man die API maßgeblich mit aus der Taufe gehoben, und von AMDs InHouse OpenGL Guru Graham Sellers gibt es den offiziellen Vulkan Leitfaden (http://www.amazon.de/Vulkan-Programming-Guide-Official-Learning/dp/0134464540), andererseits wurde NV bereits am Releasetag mit validierten Treiber gelistet und AMD bis heute nicht. :confused:

[iuno]

Wie kommt es eigentlich dass bis heute keine einzige AMD-Karte offiziell Vulkan (https://www.khronos.org/conformance/adopters/conformant-products#vulkan)-kompatibel (https://www.khronos.org/conformance/adopters/conformant-companies#vulkan) ist?
Das ist eine Auflistung der die konformen Produkte und eben der zugehoerigen Unternehmen. AMDs frueher Windows-Treiber besteht den Konformitaetstest nicht, ergo kein Eintrag in der Liste.
Fuer AMD ist der Zeitpunkt halt nicht ideal, da ohnehin viel an den Treibern umgebaut wird, aber das wird schon noch.

Auf gpuopen gibt es einen neuen Eintrag zu Validierungsschichten: http://gpuopen.com/using-the-vulkan-validation-layers/


EDIT: Der neue Crimson 16.3 soll den Konformitaetstest bestehen, also muesste die Tabelle bald aktualisiert werden ;)

​Vulkan™ Support(1)
[...]
(1)Product is conformant with Vulkan 1.0 Specification. Vulkan™
http://support.amd.com/en-us/kb-articles/Pages/AMD_Radeon_Software_Crimson_Edition_16.3.aspx

[kruemelmonster]

Konform ist passender als kompatibel, richtig.
Die Frage für mich ist warum das schon wieder ein Thema bei AMD sein muss "was noch wird". Wenn ich von einer Firma den ersten Vulkan-konformen Treiber erwartet habe, dann von den Mantle Erfindern.
Und ob es dann jetzt der 16.3 für die Listung wird ist imo auch fraglich: in dem gut zwei Wochen großen Zeitfenster für das WHQL-Logo hätte der Vulkan-Stempel schon mit abfallen müssen. Es werden bereits drei ARM Mali GPUs als konform gelistet mit der Datumsangabe 18. bzw 19. März, es ist also wohl nicht so dass die Seite erst nach der Veröffentlichung eines Treibers aktualisiert wird.
Ich will hier keinen Teufel an die Wand malen, natürlich wird AMD schnellstmöglich etwas bringen, aber Zuversicht in den roten Softwarestack erzeugt die Situation bei mir nicht unbedingt wenn selbst Intel schon mit einem entsprechenden Treiber gelistet ist.

[iuno]

Naja es gibt halt intern Release-Zyklen, die eingehalten werden sollen und ein Release wird gemacht wenn er soweit ist. Das hat halt zeitlich nicht zum Datum der Veroeffentlichung der Vulkan Spezifikation gepasst, dann haben sie halt einen Beta-Treiber mit frueherem Stand rausgebracht, damit man immerhin etwas hat. Was solls, intern wird schon laenger damit gearbeitet und fuer den Endnutzer bringt Vulkan Support eh noch nichts. Klar, toll ist das keinesfalls aber eben auch kein wirkliches Problem.

Und wenn sie es hinschreiben ist der Treiber 100%ig konform. Ob es auf der Khronos Seite sofort uebernommen wird ist doch nicht so wichtig.

Was heisst da "selbst Intel". Die Unterschiede im Budget sind dir aber bewusst oder?



btw:
Und Treiber-Unterstützung für Windows ist bei AMD & NV nun auch mit den normalen Consumer-Treibern vorhanden.
Falls die in den nächsten Monaten über Windows Update ausgerollt werden, würde Vulkan schnell eine ziemlich hohe Verbreitung erfahren.
Was bringt eigentlich WDDM2? Du redest doch oefter darueber ;)
In der Liste von Khronos mit den konformen Produkten (https://www.khronos.org/conformance/adopters/conformant-products#vulkan) ist Nvidia bisher auch nur fuer Win<10, WDDM1 gelistet.

[ScottManDeath]

Die Khronos Seite ist die Referenz bezüglich Conformance. Erst wenn eine Implementierung dort auftaucht ist sie de jure konform und dann kann das auch so in den Release Notes des IHVs so übernommen werden.

[iuno]

Ja, das ist die Referenz... wenn AMD die Tests gemacht hat und Treiber/Hardware sich konform verhalten haben (und darum ging es), das Ergebnis eingereicht haben und die Khronos Group nur noch kein Update auf der Seite gemacht hat, sehe ich das Problem nicht. Wenn das review nicht positiv war, duerften sie streng genommen auch "Vulkan" nicht im Zusammenhang mit dem Treiber als Marke verwenden.

Interessant ist ueberigens auch, dass die ImgTec. GPUs nicht in einem Soc getestet wurden, sondern offenbar auf einer Erweiterungskarte in einem PC mit Intel CPU und Ubuntu

[aufkrawall]

Was bringt eigentlich WDDM2? Du redest doch oefter darueber ;)
In der Liste von Khronos mit den konformen Produkten (https://www.khronos.org/conformance/adopters/conformant-products#vulkan) ist Nvidia bisher auch nur fuer Win<10, WDDM1 gelistet.
Es gibt doch mehrere Einträge für mehrere GPUs. Darunter nicht nur Familien, sondern auch einzelne. Und die werden auch für Win 10 aufgezählt.

[iuno]

Das stimmt natuerlich, wie konnte ich das vorhin uebersehen? :redface:

[ScottManDeath]

Die Release Notes wurden aktualisiert:



(1)Product is based on the Vulkan 1.0 Specification and has been submitted to, and is expected to pass, the Khronos Conformance Process. Current conformance status can be found at www.khronos.org/conformance. Vulkan™ and the Vulkan™ logo are trademarks of the Khronos Group Inc.​

[iuno]

:facepalm:
Naja immerhin scheint es so zu sein wie ich dachte. Wenn sie es submittet haben ist ihnen das Ergebnis ja bekannt, es wurde halt noch nicht abgenickt.

[SaschaW]

Intel hat jetzt auch endlich Windowstreiber die Vulkan auf GPUs der 6. Generation unterstützten : https://software.intel.com/en-us/blogs/2016/03/14/new-intel-vulkan-beta-1540204404-graphics-driver-for-windows-78110-1540

(Achtung : Die Links sind irgendwie noch buggy und zeigen teilweise auf falsche Treiber)

Unterstützte GPUs :

6th Generation Intel® Core processors, Intel Core™ M, and related Pentium® processors with Intel® HD Graphics 510, 515, 520, 530, Intel® Iris™ Graphics 540, Intel® Iris™ Graphics 550, and Intel® Iris™ Pro Graphics 580.

[Kartenlehrling]

keine iris pro 6100 und 6200 ?

[deekey777]

keine iris pro 6100 und 6200 ?
Sind doch Schnee von gestern.

Im Ernst: Typisch Intel, sie veröffentlichen gern Grafiktreiber für einzelne Generationen.

[Ganon]

Steht doch alles im Link? Unterstützt doch so ziemlich alle Intel GPUs, oder fehlt da noch was?

[Kartenlehrling]

der Treiber schon aber Vulkan 1.0 ist nur für die 6. Generation, dabei ist doch gerade der iris pro 6200 intels schnellste iGPU.

This driver also adds new Beta support for the Vulkan 1.0 API for 6th Generation Intel Core and related processors.

Dieser Treiber fügt auch neue Beta Unterstützung für die Vulkan 1.0 API für 6. Generation Intel Core und die damit verbundenen Prozessoren.

[Ganon]

Achso, das ist ja alles verwirrend geschrieben :ugly: Sorry.

[Unicous]

Tiago Sousa
@idSoftwareTiago

Lead Renderer Programmer @ id Software

While on topic of IHVs poking. We are seeing big gains with async compute - just saying.


https://twitter.com/idSoftwareTiago/status/709814902362275841

Könnte auf einen Vulkan-Renderpfad für Doom 4 hindeuten oder setzt id Tech auf einmal auf DX12?:eek::freak:

[kruemelmonster]

Was heisst da "selbst Intel". Die Unterschiede im Budget sind dir aber bewusst oder?
Wenn ich von einer Firma den ersten Vulkan-konformen Treiber erwartet habe, dann von den Mantle Erfindern.

...und die Khronos Group nur noch kein Update auf der Seite gemacht hat, sehe ich das Problem nicht.
Es werden bereits drei ARM Mali GPUs als konform gelistet mit der Datumsangabe 18. bzw 19. März, es ist also wohl nicht so dass die Seite erst nach der Veröffentlichung eines Treibers aktualisiert wird.

Stand heute, exakt einen Monat nach dem Release von Vulkan, wird auf der Khronos Seite weiterhin keine einzige AMD-Lösung als konform gelistet.
Als ob nach Kennedys Ankündigung zum Mond zu fliegen die Russen und Chinesen zuerst dort gelandet wären...

[iuno]

Die Seite wurde auch schon aktualisiert, seit AMD den Treiber veroeffentlicht hat. Samsung stand vorher nicht drin. Die Zweifel sind also berechtigt :freak:
Verwirrend sind in der Liste auch die Datumsangaben: 18./19. Maerz bei ARM bzw. 1. April bei Samsung. Was soll das darstellen und wieso ist es fuer die Liste wichtig?

[Chris Lux]

https://twitter.com/idSoftwareTiago/status/709814902362275841

Könnte auf einen Vulkan-Renderpfad für Doom 4 hindeuten oder setzt id Tech auf einmal auf DX12?:eek::freak:
Dir ist schon aufgegangen, dass Doom auch für die PS4 und XBox One kommt?

[deekey777]

Dir ist schon aufgegangen, dass Doom auch für die PS4 und XBox One kommt?
Doom wird exklusiv im Windows Store vertrieben. X-D DX12 bestätigt.

Man kann aus dem Tweet auch herauslesen, dass unter Windows 10 das Spiel DirectX12, auf anderen Plattformen DirectX11 nutzt. Oder eben nur Vulkan, sofern dieses AC überhaupt nutzen kann (keine Ahnung). Oder nur OpenGL 4.4 auf dem PC. Oder nur DirectX11 auf dem PC.

Sprich: Man liest daraus, was man sehen will.

[iuno]

id arbeitet auf jeden Fall an Vulkan, allerdings wohl vorrangig wegen Android...

Natuerlich kann Vulkan Async Compute. Genau wie in DX12 gibt es compute, gfx und copy/transfer queues

[Achill]

Die Seite wurde auch schon aktualisiert, seit AMD den Treiber veroeffentlicht hat. Samsung stand vorher nicht drin. Die Zweifel sind also berechtigt :freak:
Verwirrend sind in der Liste auch die Datumsangaben: 18./19. Maerz bei ARM bzw. 1. April bei Samsung. Was soll das darstellen und wieso ist es fuer die Liste wichtig?

Evtl. Marketing: "Wer hats [zuerst] erfunden?!" ... die Schweizer ;)

Wer war eigentlich der Khronos President Neil Trevett (https://en.wikipedia.org/wiki/Neil_Trevett) nochmal? Er könnte da bestimmt etwas dunkel ins Licht bringen. Bei der Liste wäre es auch interessant, wenn ein IHV noch nicht alle Test schafft, welche diese sind - dann kann man das als Entwickler entsprechend bewerten. So scheint der Eindruck zu sein, das man es gar nicht kann...

[Unicous]

Dir ist schon aufgegangen, dass Doom auch für die PS4 und XBox One kommt?
Doom wird exklusiv im Windows Store vertrieben. X-D DX12 bestätigt.

Man kann aus dem Tweet auch herauslesen, dass unter Windows 10 das Spiel DirectX12, auf anderen Plattformen DirectX11 nutzt. Oder eben nur Vulkan, sofern dieses AC überhaupt nutzen kann (keine Ahnung). Oder nur OpenGL 4.4 auf dem PC. Oder nur DirectX11 auf dem PC.

Sprich: Man liest daraus, was man sehen will.

Ich sehe ihr habt offensichtlich auf den Link geklickt.

Alessio ‏@AlexiousRahl

@idSoftwareTiago Hopefully that doesn't leave NVIDIA users in the dust in DOOM :(
Tiago Sousa ‏@idSoftwareTiago

@AlexiousRahl all good, everyone getting some love : )


Natürlich brauchen die Konsolen auch Optimierungen für Nvidia und Intel, ist ja klar.:rolleyes:

Aber das Statement ist sehr ambivalent geschrieben und könnte sich nur auf die Konsolen beziehen, dann verstehe ich aber den Bezug auf andere IHVs nicht.

[deekey777]

Vielleicht sollte man einfach nichts reinlesen, was so nicht steht?

Nochmal: Du hast was von Vulkan oder DX12 geschrieben, nicht ich oder ein anderer.

[Unicous]

Da hast du recht, dennoch kannst du mir gerne erklären was er mit

all good, everyone getting some love : ) meint, wenn er nur von Konsolen spricht.

Und ja, ich weiß, was ich geschrieben habe. Aber danke fürs Erinnern.:up:

[d2kx]

xXyZ4YaktyU

Valves GDC talk über Vulkan
beginnt @ 1:27:25

[Kartenlehrling]

Wo finde ich den diesen CPU Thread demo aus dem Video, die Fish-demo von Nvidia will bei mir nicht laufen.

[SaschaW]

Wo finde ich den diesen CPU Thread demo aus dem Video, die Fish-demo von Nvidia will bei mir nicht laufen.

Welches genau? Es gibt eins für Cinder (https://github.com/cinder/Cinder/tree/vulkan/samples/_vulkan_explicit/FishTornado) und im LunarG SDK sind auch zwei Multi-Threaded Beispiele drin (Smoke und Hologram).

[ScottManDeath]

@Kartenlehrling, auf welcher Hardware funktioniert die NVIDIA Fish! Demo nicht?

[iuno]

endlich offiziell: https://youtu.be/l88n8a4Yphw?t=69
(UE4 mit Vulkan als "2016 feature")

[SaschaW]

@Kartenlehrling, auf welcher Hardware funktioniert die NVIDIA Fish! Demo nicht?

Zumindest einige der NV-Demos nutzen u.a. deren Extension um GLSL direkt aus Vulkan heraus laden zu können. Z.B. die Chopper-Demo. Die laufen dann folglich nur auf deren Hardware, es sei denn man erzeugt die SPIR-V files und passt den Code dann entsprechend an.

[BlacKi]

gibt es denn schon eine liste oder gar einen eigenen fred für kommende vulkan spiele?

[iuno]

zusammen mit dx12: https://www.forum-3dcenter.org/vbulletin/showthread.php?t=565059

[Brillus]

Die Seite wurde auch schon aktualisiert, seit AMD den Treiber veroeffentlicht hat. Samsung stand vorher nicht drin. Die Zweifel sind also berechtigt :freak:
Verwirrend sind in der Liste auch die Datumsangaben: 18./19. Maerz bei ARM bzw. 1. April bei Samsung. Was soll das darstellen und wieso ist es fuer die Liste wichtig?

Also am 16.3 zu dem Khronos talk, stand AMD als Conformant auf den Khronos slides.

https://www.youtube.com/watch?v=ZslV3s6wu5c (15:38)

[d2kx]

Vulkan wird nun mit dem frühen AMDGPU PRO/Hybrid-Stack für GCN 1.2 (und experimentell GCN 1.1) Chips unter Linux unterstützt: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=571804

http://i.imgur.com/3mDlcsr.png

Läuft bei mir auf einer R9 390.

[wn612953]

Vulkan wird nun mit dem frühen AMDGPU PRO/Hybrid-Stack für GCN 1.2 (und experimentell GCN 1.1) Chips unter Linux unterstützt: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=571804

http://i.imgur.com/3mDlcsr.png

Läuft bei mir auf einer R9 390.


Bist du ein AMD / Radeon Technologies Group Mitarbeiter?

[wn612953]

Vulkan Code Begins Appearing For Unreal Engine 4

http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Code-UE4


;)

Hoffentlich gibts dann auch vernünftiges AA :freak:.

[iuno]

siehe antwort im ue thread ;)
waere mal interessant, jemand (*hust d2kx*) wuerde die aktuelle ue4 laden und ueber den stand der vk implementierung berichten ;)

[samm]

Bist du ein AMD / Radeon Technologies Group Mitarbeiter?Er ist Treiber-Tester afaik

Mal sehen, was Epic in die Engine noch so einbaut, das zusammen mit DX12 (nicht) ausgeführt wird, um die No. 1 des diskreten GPU-Markts nicht schlecht dastehen zu lassen ;) Ne ernsthaft, so weit wie die UE4 sich gerade verbreitet bin ich sehr froh um die Bewegung hin zur low overhead API, und egoistisch auch wegen der Plattform-Unabhängigkeit - ich möchte die Microsoftsche Überwachungs- und Vendor-Lock-Maschinerie nicht allzu weit bedienen.

Auch was Valve bezüglich Source Port in den GDC Talks bisher gesagt hat, lässt mich aufhorchen bezüglich Latenz-Optimierung. Ich bin vielleicht zu sehr auf VR und auf Games fixiert, weil ich das einfach faszinierend finde und für einen grossen Technologie-Treiber halte, aber niedrige Latenzen sind gut für praktisch jede Sorte Anwendung.

[Wake]

AMD vs. NVIDIA Vulkan & OpenGL Linux Performance With The New Drivers (http://www.phoronix.com/scan.php?page=article&item=amd-nv-glvk&num=2)

AMD legt ordentlich zu, während der Performancegewinn bei Nvidia zwar auch vorhanden aber eher verhalten ist.

[Brillus]

AMD vs. NVIDIA Vulkan & OpenGL Linux Performance With The New Drivers (http://www.phoronix.com/scan.php?page=article&item=amd-nv-glvk&num=2)

AMD legt ordentlich zu, während der Performancegewinn bei Nvidia zwar auch vorhanden aber eher verhalten ist.

War nun auch eher zu erwarten wenn man die OpenGL-Performance von NVIDIA und AMD vergleicht, außerdem ist der OpenGL-Part im neuen AMD Treiber, nach Aussagen der Entwickler, noch nicht richtig optimiert, fehlen unter anderem die Anwendungserkennung und die entsprechenden Optimierungen.

[iuno]

Aus Talos kann man ohnehin nichts lesen, das muss man dabei auch bedenken.
Trotzdem natuerlich schoen, dass es auch in diesem Status schon ein Fortschritt ist. Fraglich nur, ob derselbe Aufwand in die Optimierung des OpenGL Pfades nicht eine bessere Ausbeute ergeben haette ;)
Um einen Trend abzulesen, muss man weiter auf eine 'ordentliche' Implementierung warten.