Vulkan Grafik-API

[Lurtz]

Gern als Beispiel genannt: Der Käufer einer GTX980 zum Launch. Der ist immer noch schneller unterwegs als der Käufer einer RX480. Nutzt seine Karte aber schon fast zwei Jahre. Unterm Strich wird er damit billiger fahren, als der RX480-Käufer.
Das Beispiel verstehe ich nicht. Was, wenn ich mir eine R9 290(X) zum Launch gekauft habe?

[fondness]

Das Beispiel verstehe ich nicht. Was, wenn ich mir eine R9 290(X) zum Launch gekauft habe?

Dann hast du den damals wesentlich teureren GK110 überlebt und du wirst auch noch GM204 überleben, dem dank fehlenden AsyncCompute bereits die Luft ausgeht.

[Unicous]

Warum darf eigentlich dieser OT-Schrott straflos stehenbleiben. Reißt euch doch mal am Riemen und scheißt den Thread nicht mit Unsinn zu.


Hier geht es um die Vulkan-API nicht um AMD vs. Nvidia (vs. Intel?).


Wie ihr eigentlich mitbekommen haben müsstet, dreht sich die Vulkan-Welt mitnichten nur um die "großen Drei" der PC-Welt.

[dargo]

btw.

Die Threadskalierung bei Doom @Vulkan ist mit 8 Threads :eek:. Mehr dazu bald....

Edit:
Auch von mir ein kleiner Vergleich mit OpenGL vs. Vulkan @720p und max. Details, habe jetzt nicht explizit nach einem Worst Case gesucht.

Haswell 4C/8T @1,5Ghz, DDR3-1600, R9 390.
56697 56698

[Atma]

Dann hast du den damals wesentlich teureren GK110 überlebt und du wirst auch noch GM204 überleben, dem dank fehlenden AsyncCompute bereits die Luft ausgeht.
Ihm geht bereits die Luft aus ... ;D

Mit einem GM204 ist in 1080p alles bequem spielbar, also hör auf so einen Fuad hier zu verbreiten.

[DanMan]

*optimieren

Ist das so? Ich weiß, dass oft für jeden IHV ein eigener Code-zweig programmiert wird, aber ist das bei Vulkan wirklich notwendig? Ich meine, normalerweise gibt es einen generischen Zweig, der immer funktionieren sollte. Klar, wenn man Intrinsics verwendet, werden die nur auf der entsprechenden Hardware laufen, aber es wird ja auch möglich sein mit Vulkan generisch zu programmieren. Kann da jemand etwas zu sagen, inwiefern Vulkan den Programmierer zwingt, speziell angepasst für jede Hardware zu programmieren? Vor allem Intel dürfte dabei ja komplett hinten runterfallen...
Es ist im Prinzip wie bei OpenGL, wo es einen offiziellen Kern an Funktionalität (ARB_*), herstellerübergreifende Erweiterungen (EXT_*) und herstellerspezifische Erw. (NV_*, AMD_*, ...) gibt. Wenn man sich jetzt z.B. nur auf die offiz. Sachen beschränkt, dann sollte das auf aller Hardware laufen, die die OpenGL/Vulkan Spezifikation erfüllt. So oder so ähnlich ist das.

[Foobar2001]

*optimieren

Ist das so?
Nicht wirklich. Es nimmt dem Treiber aber Moeglichkeiten bestimmte Optimierungen durchzufuehren, was manche aeltere GPUs benachteiligt weil sie nicht auf Vulkan & DX12 ausgelegt sind.

[-=Popeye=-]

btw.

Die Threadskalierung bei Doom @Vulkan ist mit 8 Threads :eek:. Mehr dazu bald....

Edit:
Auch von mir ein kleiner Vergleich mit OpenGL vs. Vulkan @720p und max. Details, habe jetzt nicht explizit nach einem Worst Case gesucht.

Haswell 4C/8T @1,5Ghz, DDR3-1600, R9 390.
56697 56698

Grafikkarte auch runtergetaktet?

[Frank1974]

Ich habe Doom mal neu installiert und auch einen Vergleich gemacht, Level ist "Die Gießerei", ich habe den niedrigsten Wert in OpenGL gesucht und es dann mit Vulkan verglichen, ich musste aus Gründen der Vergleichbarkeit aber im Fenstermodus die Bilder machen, weil mit Vulkan bei mir keine einzige Methode funktioniert, habe es mit allen Tricks probiert, aber leider kam nix bis auf ein schwarzes Bild.

System
Intel i5-750@3GHz, 8GB-DDR3@1500MHz, HD 7970@925MHz, Win10 x64, Treiber-16.7.2

Ingame, 1920x1080, Alles auf Max Details, bei mir Ultra, 8xTXAA

OpenGL v4.3
https://abload.de/thumb/doom_opengl_gieerei2v0uup.png (http://abload.de/image.php?img=doom_opengl_gieerei2v0uup.png)

Vulkan v1.0.17
https://abload.de/thumb/doom_vulkan_gieereidbxvm.png (http://abload.de/image.php?img=doom_vulkan_gieereidbxvm.png)

Es macht bei mir übrigens keinen Unterschied ob Vollbild oder Fenstermodus, es hat eh immer +/- 1fps gehabt.

Ist schon nicht schlecht, leider habe ich Doom schon 2 mal auf einer Mischung von Mittel und Hohen Details gespielt und auch alle Sammelobjekte und sonstiges gefunden, deshalb gibt es leider nichts mehr was ich machen kann, spiele nur Singleplayer, das Spiel war aber auch so sehr gut, bei dem Tempo merkt man eh nach wenigen Minuten nichts mehr von der Bildqualität, ich bin sogar etwas erschrocken als ich die Bilder gemacht habe, selbst bei 8xTXAA ist alles noch sehr kantig, naja wollte auch nur mal was zum Thema beitragen und nicht nur meckern, für alle die es noch spielen ist Vulkan dann doch schon eine gute Sache, knapp 50% mehr ist wirklich viel, ich habe ja schon einiges gebencht aber das ist wirklich mal ein Test der sich gelohnt hat:), bei Kämpfen ist es dann etwas weniger fps, aber das kann man wohl nur mit einer Hardware Capturing Karte machen, aber selbst dann wird man in Doom nicht wirklich einen 1:1 Test machen können, wenn man wild durch die Gegend springt und die Gegner verhalten sich auch immer etwas anders, naja egal:smile:

mfg
Frank

[dargo]

@Popeye
Nein, Powerplay halt im vollständigen CPU-Limit.

[Dural]

Vulkan läuft auf meinem system nicht mal stabil, jetzt ist wieder open gl drin.

[-=Popeye=-]

Die Thread Auslastung kannste dir glaube ich schenken Dargo, hier knallt Vulkan alles auf einen Thread und OpenGL verteilt auf alle 12 im ersten Level.

Achso Sys lief wieder mit 4GHz und TX@1074/3500.

[Foobar2001]

So ein Quatsch.

[dargo]

Die Thread Auslastung kannste dir glaube ich schenken Dargo, hier knallt Vulkan alles auf einen Thread und OpenGL verteilt auf alle 12 im ersten Level.

Ist bei mir mit AMD absolut nicht der Fall. Allerdings kann ich mir dennoch weitere Messungen sparen denn 3Ghz mit 4C/4T ist mit 123fps in meiner Testszene exakt gleich schnell wie 4C/8T. Beides im vollständigen CPU-Limit. Da habe ich mich vom Taskmanager beirren lassen. SMT bringt also absolut Null in Doom.

[Schaffe89]

Dann hast du den damals wesentlich teureren GK110 überlebt und du wirst auch noch GM204 überleben, dem dank fehlenden AsyncCompute bereits die Luft ausgeht.

Und natürlich wird man auch noch die GTX 1080 überleben und überhaupt.
Dieses Fanboygequatsche nimmt wirklich überhand in den Threads.
Weil die 290x nach 2 Jahren jetzt im Schnitt mit ach und Krach vor einer GTX 970 rangiert, lässt man sich zu solchen Aussagen hinreißen und GM204 geht die Luft aus, weil man durch Async 10% Leistung herauskitzelt, die nebenbei auch noch in einen höheren Strombedarf münden?;D

[Frank1974]

Warum darf eigentlich dieser OT-Schrott straflos stehenbleiben. Reißt euch doch mal am Riemen und scheißt den Thread nicht mit Unsinn zu.


Hier geht es um die Vulkan-API nicht um AMD vs. Nvidia (vs. Intel?).


Wie ihr eigentlich mitbekommen haben müsstet, dreht sich die Vulkan-Welt mitnichten nur um die "großen Drei" der PC-Welt.

Ich denke du meist auch meine 2 Beiträge, sorry dafür, ich habe sie selbst gelöscht, kennst du Dr. Jekyll and Mr. Hyde, das passiert bei mir ab und zu, jedenfalls so ähnlich, danach tut es mir dann auch sehr leid, ich werde dafür sorgen das so etwas nicht mehr vorkommt bei mir.

mfg
Frank

[Hübie]

Nicht wirklich. Es nimmt dem Treiber aber Moeglichkeiten bestimmte Optimierungen durchzufuehren, was manche aeltere GPUs benachteiligt weil sie nicht auf Vulkan & DX12 ausgelegt sind.

Wie stelle ich mir Instrincts vor? Müssen die nicht mehr kompiliert und abstrahiert werden? Gilt dann wohl pro Iteration (GCN1.0, 1.1 usw oder)? Bedeutet das nicht immer einen deutlich gesteigerten Aufwand für jedes Studio oder könnte man da Engine-übergreifend so etwas wie eine Bibliothek zusammenstellen?

[dargo]

Weil die 290x nach 2 Jahren jetzt im Schnitt mit ach und Krach vor einer GTX 970 rangiert, lässt man sich zu solchen Aussagen hinreißen und GM204 geht die Luft aus, weil man durch Async 10% Leistung herauskitzelt, die nebenbei auch noch in einen höheren Strombedarf münden?;D
Was habt ihr eigentlich immer mit eurem Strom? Ok... bei der Kühlung kann ich es ja noch verstehen. Schließlich lassen sich sparsamere Karten einfacher leise kühlen. Aber wegen Stromkosten? Ich zahle im Monat 20€ für Strom... und nein bin kein Selbstversorger übers Dach. Alles wird extern besorgt. Und das mit einer AMD Karte im Rechner. :eek:

[captain_drink]

Und natürlich wird man auch noch die GTX 1080 überleben und überhaupt.
Dieses Fanboygequatsche nimmt wirklich überhand in den Threads.
Weil die 290x nach 2 Jahren jetzt im Schnitt mit ach und Krach vor einer GTX 970 rangiert, lässt man sich zu solchen Aussagen hinreißen und GM204 geht die Luft aus, weil man durch Async 10% Leistung herauskitzelt, die nebenbei auch noch in einen höheren Strombedarf münden?;D

Zumal ein Gewinn durch AC auf einer AMD-Karte nur bedeutet, dass GM204 relativ zu dieser Leistung verliert, absolut ist letzterer ebenso schnell wie eh und je.
Es ist wirklich ermüdend, immer wieder diese Glaubenskämpfer-Statements lesen zu müssen, die alle Threads zumüllen.

[-=Popeye=-]

So ein Quatsch.

Sorry war ein Ablesefehler meinerseits im Afterburner. Keine Ahnung was da gerade reingefunkt hat, möglicherweise der gleichzeitige Start von AIDA.

[Hübie]

Ich habe Doom mal neu installiert und auch einen Vergleich gemacht, Level ist "Die Gießerei", ich habe den niedrigsten Wert in OpenGL gesucht und es dann mit Vulkan verglichen, ich musste aus Gründen der Vergleichbarkeit aber im Fenstermodus die Bilder machen, weil mit Vulkan bei mir keine einzige Methode funktioniert, habe es mit allen Tricks probiert, aber leider kam nix bis auf ein schwarzes Bild.

System
Intel i5-750@3GHz, 8GB-DDR3@1500MHz, HD 7970@925MHz, Win10 x64, Treiber-16.7.2

Ingame, 1920x1080, Alles auf Max Details, bei mir Ultra, 8xTXAA

OpenGL v4.3
https://abload.de/thumb/doom_opengl_gieerei2v0uup.png (http://abload.de/image.php?img=doom_opengl_gieerei2v0uup.png)

Vulkan v1.0.17
https://abload.de/thumb/doom_vulkan_gieereidbxvm.png (http://abload.de/image.php?img=doom_vulkan_gieereidbxvm.png)

Es macht bei mir übrigens keinen Unterschied ob Vollbild oder Fenstermodus, es hat eh immer +/- 1fps gehabt.

Ist schon nicht schlecht, leider habe ich Doom schon 2 mal auf einer Mischung von Mittel und Hohen Details gespielt und auch alle Sammelobjekte und sonstiges gefunden, deshalb gibt es leider nichts mehr was ich machen kann, spiele nur Singleplayer, das Spiel war aber auch so sehr gut, bei dem Tempo merkt man eh nach wenigen Minuten nichts mehr von der Bildqualität, ich bin sogar etwas erschrocken als ich die Bilder gemacht habe, selbst bei 8xTXAA ist alles noch sehr kantig, naja wollte auch nur mal was zum Thema beitragen und nicht nur meckern, für alle die es noch spielen ist Vulkan dann doch schon eine gute Sache, knapp 50% mehr ist wirklich viel, ich habe ja schon einiges gebencht aber das ist wirklich mal ein Test der sich gelohnt hat:), bei Kämpfen ist es dann etwas weniger fps, aber das kann man wohl nur mit einer Hardware Capturing Karte machen, aber selbst dann wird man in Doom nicht wirklich einen 1:1 Test machen können, wenn man wild durch die Gegend springt und die Gegner verhalten sich auch immer etwas anders, naja egal:smile:

mfg
Frank

Krass. Wer hätte damals gedacht dass Tahiti noch einmal so einen Zuwachs bekommen kann. :up: Seit ich Doom kenne finde ich es umso mehr Schade, dass Vulkan wahrscheinlich nie zu einer weiten Verbreitung kommen wird, die diese API eigentlich verdient hätte. Microsoft und Apple lehnen sich ja aus unerklärlichen Gründen dagegen. Es wäre meines Erachtens nach für beide jedoch einfacher die "Verantwortung" dafür abzugeben. :confused:

[Pirx]

Ohne DX12 ist M$ tot und jeder, der sich halbwegs auskannte, wusste, welches Potenzial in Tahiti steckt.

[Frank1974]

Krass. Wer hätte damals gedacht dass Tahiti noch einmal so einen Zuwachs bekommen kann. :up: Seit ich Doom kenne finde ich es umso mehr Schade, dass Vulkan wahrscheinlich nie zu einer weiten Verbreitung kommen wird, die diese API eigentlich verdient hätte. Microsoft und Apple lehnen sich ja aus unerklärlichen Gründen dagegen. Es wäre meines Erachtens nach für beide jedoch einfacher die "Verantwortung" dafür abzugeben. :confused:

Ja das stimmt, ich habe die Karte jetzt über 4 1/2 Jahre, so etwas habe ich auch noch nie gesehen, bei einigen Games ging mal über die Treiber 5%, aber das so eine alte Karte nochmal um 50% beschleunigt werden kann, hätte ich nicht gedacht, ich musste es auch erst sehen um es zu glauben, ich hoffe du nimmst mir meine 2 negativen Posts nicht krumm, ich bin eigendlich sehr freundlich, weiß nicht was mich geritten hat, sorry, ich hoffe ich kann hier jetzt noch nomal weiter posten ohne das ich ausgeschlossen werde.

mfg
Frank

[Hübie]

Welche Posts? :confused: Schwamm drüber. Bin da nicht so empfindlich :D

@Pirx: Damals habe ich mir die ISA angesehen und oft kam mir dann die Frage auf, wieso der Unterschied zwischen Papier und Praxis so groß ist. Lag wohl einfach daran dass die Hardware an der API "vorbei" designed wurde. :| Ich erinnere mich noch an eine Diskussion über Tahiti in Metro 2033. Da stand Tahiti afair nicht gut da und so richtig erklären konnte es niemand.

[danarcho]

Wie stelle ich mir Instrincts vor? Müssen die nicht mehr kompiliert und abstrahiert werden? Gilt dann wohl pro Iteration (GCN1.0, 1.1 usw oder)? Bedeutet das nicht immer einen deutlich gesteigerten Aufwand für jedes Studio oder könnte man da Engine-übergreifend so etwas wie eine Bibliothek zusammenstellen?
Im Grunde genommen sind Intrinsische Funktionen build-in functions, die (meistens) genau auf unterliegende hardware instructions mappen. Dadurch, dass sie als normale C-Funktionen zur Verfügung stehen, muss man sich nicht um Register kümmern. Gleichzeitig kann man extrem präzise programmieren, fast wie bei Assembler. Der Compiler hat dabei noch Möglichkeiten ein paar Standard-Optimierungen durchzuführen, wie constant propagation oder dead code elimination.
Voraussetzung ist natürlich, dass die Instruktionen von der Hardware unterstützt werden. Soweit ich verstanden habe, können die neueren GCN Versionen alles, was die älteren können und evtl. ein paar Funktionen mehr.
Vielleicht vergleichbar mit SSE2,3,4...
So gesehen kann man die Intrinsics auch auf keinen Fall mit so einem Müll wie Gameworks vergleichen. Intrinsics erlauben einen deutlich größeren Zugriff auf die Hardware und bedeuten hier eine Offenlegung.
Die armen Hunde, die versuchen mit dem nouveau Treiber die nVidia hardware zu reverse-engineeren, würden ausflippen bei so viel Dokumentation.

[StefanV]

Ich erinnere mich noch an eine Diskussion über Tahiti in Metro 2033. Da stand Tahiti afair nicht gut da und so richtig erklären konnte es niemand.
Weil das ja auch wieder ein von nVidia 'unterstütztes' Spiel war, dass ja auch noch PhysX genutzt hat. Wer weiß, was die da getrieben haben...

[Hübie]

Im Grunde genommen sind Intrinsische Funktionen build-in functions, die (meistens) genau auf unterliegende hardware instructions mappen. Dadurch, dass sie als normale C-Funktionen zur Verfügung stehen, muss man sich nicht um Register kümmern. Gleichzeitig kann man extrem präzise programmieren, fast wie bei Assembler. Der Compiler hat dabei noch Möglichkeiten ein paar Standard-Optimierungen durchzuführen, wie constant propagation oder dead code elimination.
Voraussetzung ist natürlich, dass die Instruktionen von der Hardware unterstützt werden. Soweit ich verstanden habe, können die neueren GCN Versionen alles, was die älteren können und evtl. ein paar Funktionen mehr.
Vielleicht vergleichbar mit SSE2,3,4...
So gesehen kann man die Intrinsics auch auf keinen Fall mit so einem Müll wie Gameworks vergleichen. Intrinsics erlauben einen deutlich größeren Zugriff auf die Hardware und bedeuten hier eine Offenlegung.
Die armen Hunde, die versuchen mit dem nouveau Treiber die nVidia hardware zu reverse-engineeren, würden ausflippen bei so viel Dokumentation.

Danke für die Erklärung :up: Zeigt mir aber auch dass ich mich da mal einlesen muss :D Gameworks war da um die Fahnen für den (NVIDIA-) PC hochzuhalten. Leider halbherzig, halbgar, ausschließlich für Studios die zu Kreuze kriechen und dann eben mit viel zu später Verbreitung auf github mit Knebel-Lizenz.
Just my 2 cents...

[DanMan]

Achtung, Achtung, eine Durchsage:

Sie befinden sich im Technologie-Forum. Dort Unterhält man sich über Technologie. *duh*
Die auf der Durchreise befindlichen Hooligans mögen sich bitte zu den Ausgängen bewegen. Vielen Dank für Ihr Verständnis.

[dargo]

Einige Details zu Doom.

Digital Foundry: Will we see async compute in the PC version via Vulkan?

Billy Khan: Yes, async compute will be extensively used on the PC Vulkan version running on AMD hardware. Vulkan allows us to finally code much more to the ;metal'. The thick driver layer is eliminated with Vulkan, which will give significant performance improvements that were not achievable on OpenGL or DX.

Digital Foundry: Do you foresee a time where async compute will be a major factor in all engines across formats?

Billy Khan: The time is now, really. Doom is already a clear example where async compute, when used properly, can make drastic enhancements to the performance and look of a game. Going forward, compute and async compute will be even more extensively used for idTech6. It is almost certain that more developers will take advantage of compute and async compute as they discover how to effectively use it in their games.

Digital Foundry: What are your thoughts on adopting Vulkan/DX12 as primary APIs for triple-A game development? Is it still too early?

Axel Gnetting: I would advise anybody to start as soon as possible. There is definitely a learning curve, but the benefits are obvious. Vulkan actually has pretty decent tools support with RenderDoc already and the debugging layers are really useful by now. The big benefit of Vulkan is that shader compiler, debug layers and RenderDoc are all open source. Additionally, it has full support for Windows 7, so there is no downside in OS support either compared to DX12.

Tiago Sousa: From a different perspective, I think it will be interesting to see the result of a game entirely taking advantage by design of any of the new APIs - since no game has yet. I'm expecting to see a relatively big jump in the amount of geometry detail on-screen with things like dynamic shadows. One other aspect that is overlooked is that the lower CPU overhead will allow art teams to work more efficiently - I'm predicting a welcome productivity boost on that side.


http://www.eurogamer.net/articles/digitalfoundry-2016-doom-tech-interview

[Screemer]

gibts eigentlich von bethesda ankündigungen zu spielen die idtech6 nutzen werden? idtech5 wurde ja zumindest ein paar mal weiterverarbeitet.

[Atma]

gibts eigentlich von bethesda ankündigungen zu spielen die idtech6 nutzen werden? idtech5 wurde ja zumindest ein paar mal weiterverarbeitet.
Ich gehe stark davon aus, dass das nächste Wolfenstein mit id Tech 6 erscheinen wird ;)

[dargo]

Also noch ein garantierter Vulkantitel. :D

[Arcanoxer]

Dann hast du den damals wesentlich teureren GK110 überlebt und du wirst auch noch GM204 überleben, dem dank fehlenden AsyncCompute bereits die Luft ausgeht.Überlebt?
Für die R290(x) gibt es noch immer kein Linux support.
Und das für die Karte mit der damals Mantle gehypt wurde.

[Achill]

Überlebt?
Für die R290(x) gibt es noch immer kein Linux support.
Und das für die Karte mit der damals Mantle gehypt wurde.

Mit 1000x wiederholen wird es auch nicht richtig, Anleitung für gentoo: https://wiki.gentoo.org/wiki/Amdgpu ... das kann man natürlich auch für andere Distris machen.

Oder anders, wie konnte deine oft zitierte Seite 'phoronix.com' nur schon folgenden Test (9. April) machen: https://www.phoronix.com/scan.php?page=news_item&px=Radeon-VLK-Windows-Linux
oder (26. Juni): http://www.phoronix.com/scan.php?page=article&item=amdgpu-rx480-linux&num=11

http://www.phoronix.net/image.php?id=2016&image=ttp_amdwin_2

http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=56722&stc=1&d=1468678085

[Hübie]

Interessant ist, dass Tiago sagt es befände sich noch kein Titel mit reinen "next-gen-API-Genen" auf dem Markt. Vor allem was D3D12 angeht wohl ein interessanter Aspekt. Aber auch Vulkan wird vielleicht noch einmal profitieren können wenn ein reiner LL-Ansatz neu geschrieben und danach designed wird.

@Unicous: Einfach so tun, als wären die gar nicht da :D

[dargo]

Interessant ist, dass Tiago sagt es befände sich noch kein Titel mit reinen "next-gen-API-Genen" auf dem Markt.
Ist doch nichts Ungewöhnliches in der Übergangszeit.

[d2kx]

http://www.libretro.com/wp-content/uploads/2016/07/140228_38849_ultra.jpg

First ever revolutionary N64 Vulkan emulator coming soon (http://www.libretro.com/index.php/first-ever-revolutionary-n64-vulkan-emulator-coming-soon-only-for-libretro-parallei/)
Libretro.com

This is the first N64 emulator project ever so far to receive Vulkan support.

This is the first time ever that an emulator takes advantage of asynchronous compute (exclusive only to DirectD12/Vulkan) for hardware rasterization of an emulated GPU.

This is the first time ever that the Angrylion renderer has been ported to a graphics API. It is the first time an RDP LLE video renderer for N64 has been capable of running at fullspeed. It marks a shift away from decades of inaccurate high-level emulation of the N64’s RDP which made for buggy N64 emulation in general.

[-/\-CruNcher-/\-]

Interessant ist, dass Tiago sagt es befände sich noch kein Titel mit reinen "next-gen-API-Genen" auf dem Markt. Vor allem was D3D12 angeht wohl ein interessanter Aspekt. Aber auch Vulkan wird vielleicht noch einmal profitieren können wenn ein reiner LL-Ansatz neu geschrieben und danach designed wird.

@Unicous: Einfach so tun, als wären die gar nicht da :D

Quantum Brake ist das einzige was momentan in diese Richtung geht.

[Hübie]

Hat aber mit seiner Upscaling-Geschichte (imo) reingeschissen.

[Rente]

Das kannst du auf dem PC inzwischen abstellen, dann bleibt allerdings ein massiver Performancebedarf (wegen der AA-Lösung).

[Hübie]

...was auch nicht viel besser ist :D Das Spiel kann man so in dem Zustand wegwerfen und in zwei Jahren mit dicken Volta oder dem Nachfolger von Vega (wie hieß der gleich:confused:) noch einmal heraus kramen.

[SaschaW]

Sry, aber was hat Quantum Break mit Vulkan zu tun? Irgendwie driftet der Thread hier total ab :/

[dargo]

Naja... es sind beides LL-APIs. Eine gewisse Diskussion zwischen beiden wird sich nicht vermeiden lassen. :)

[Ex3cut3r]

Bei Doom ist aber eine Fury X schneller als eine 1070er

27zvYGSGrng

ab 04:13

allerdings weiß ich die Taktraten nicht. Schätze mal Stock.

Nach diesem Video musste man eigentlich ein Fury X kaufen, nur hat die 4GB weniger Speicher, frisst mehr Strom, und ist ist allen anderen Games erheblich langsamer. :freak:

[VooDoo7mx]

Bei Doom ist aber eine Fury X schneller als eine 1070er

http://youtu.be/27zvYGSGrng

ab 04:13

allerdings weiß ich die Taktraten nicht. Schätze mal Stock.

Nach diesem Video musste man eigentlich ein Fury X kaufen, nur hat die 4GB weniger Speicher, frisst mehr Strom, und ist ist allen anderen Games erheblich langsamer. :freak:

Ja das ist auch stock. Es gibt 1070 Karten die weniger als die FE kosten und out of the Box fast 2GHz Boost takt halten. Lass sowas mal gegen die Fury laufen.

Desweiteren würde ich den Vulkan BETA Patch für Doom jetzt nicht für irgendwelche Vergleiche herziehen.

1. Async Compute funktioniert noch nicht bei nVidia Karten. Gut bei Maxwell, wird es kaum was bringen, bei Pascal hingegen schon auch wenn nicht so viel wie bei AMD.
2. Lässt sich das Spiel nicht wirklich benchmarken. Es lassen sich keine Timedemos erstellen und somit keine 1zu1 Vergleiche erzielen. Gerade unter Vulkan ist der Performance gain komplett wonky unter Doom. Es gibt z.B. Szenen da gewinnt eine AMD Karte im CPU Limit 50% FPS und eine Nvidia Karte von mir aus 25% und in einer anderen Szene im gleichen Level ist es genau umgedreht. (alle Zahlen frei erfunden)
3. Gibt es mit nVidia Karten irgendwie noch massive Probleme das das game komplett unrund unter Vulkan läuft, obwohl permanent 60fps. Schau dir mal den Doom Thread im Spieleforum. das haben Spieler mit Kepler, Maxwell und Pascall Karten. Unter Open GL ist alles sauber.

Ich würde erst mal warten bis der Vulkan Patch final ist und auch unter nVidia Karten normal läuft. Aber selbst dann wird es sein, dass sich eine Fury X leicht vor eine Stock GTX980 Ti schiebt oder gleichzieht. das gleiche wird auch bei RX480 vs GTX 1060 sein.
Für mich ist das jetzt kein Weltuntergang. Ich verstehe auch jetzt nicht die Fanboy Jubelarien weil in einen zigen Titel die Performance gleich zieht.
Meine 980ti läuft mit über 1,4GHz da sieht auch unter Vulkan keine Fury X mehr Land.

[Ex3cut3r]

Ja das was dran an deinen Punkten, aber momentan muss man sagen, dass Amd die Nase jetzt in Vulkan/DX12 massiv vorn hat. Bei Quantum Break sieht man das sehr gut.

[gedi]

Ich denke es gibt eine Tendenz:

http://up.picr.de/26233786mx.jpg

[Foobar2001]

Ich wuerd echt davon abraten noch 4GB-Karten zu kaufen :frown:

[dargo]

Ich denke es gibt eine Tendenz:

http://up.picr.de/26233786mx.jpg
Die "Tendenz" war vorhersehbar. ;) Wobei hier bei Pascal noch was im Argen ist.

Edit:
Moment... da ist allgemein bei NV was im Argen. 780TI knapp vor 980? :|

Ich wuerd echt davon abraten noch 4GB-Karten zu kaufen :frown:
Bei 3440x1440 auf jeden Fall. Es sei denn man kann damit leben in dem einen oder anderen Spiel die Texturauflösung eine Stufe zu reduzieren.

[VooDoo7mx]

Ich finds auch immer wieder lustig. :D Dabei übersehen die wie wichtig der Vorteil von low level zb. für die ganzen Hawaiis/Grenadas/Tahitis ist. Und natürlich auch aktuell Polaris.

Edit:
Noch lustiger ist, dass ständig die Fury X betrachtet wird wo eine Fury Nitro @1050Mhz kaum bis gar nicht langsamer ist, dabei aber mittlerweile nur 350€ (kurzeitig sogar 312€) kostet.

Auch 4 Jahre alte Kepler Karten wie z.B. die GTX 670 profitieren massiv unter Vulkan im CPU limit. Und jetzt?

Und warum ist die Fury kaum langsamer als die Fury X? Weil sie ihre dicke Rechenleistung wegen des ineffizienten Designs nicht auf die Straße bekommt.

Auf der einen Seite kommen bei dir permanent Jubelarien auf LL APIs (teh future) und dann verkennst du, dass gerade unter so einer API der Abstand zwischen Fury und Fury X nochmal steigen wird, da einfach die Hardware besser ausgenutzt werden kann. Verstehe ich nicht. :confused:

Ja das was dran an deinen Punkten, aber momentan muss man sagen, dass Amd die Nase jetzt in Vulkan/DX12 massiv vorn hat. Bei Quantum Break sieht man das sehr gut.

Ich weiß nicht wo du einen massiven Vorteil siehst. AMD gewinnt nur die meisten % im Vergleich zu DX11. Dies hat 2 ganz einfache Gründe.

1. Der Open GL Treiber von AMD ist einfach nur abartig schlecht. Sieht man auch immer gut Linux Benchmarks. Wo teilweise eine GTX960 an einer Fury X vorbeizieht. :rolleyes: Da wirken die gewaltigen Gewinne unter Vulkan viel beeindruckender als unter nvidia wo außer in szenen im CPU Limit nicht viel rumkommt. Wieso auch, wenn Async Compute noch deaktiviert ist und der Open GL Treiber schon vorher sehr gut war?

2. Auch der AMD Treiber unter DX 11 war nicht das gelbe vom Ei und erzeugt eine viel höhere CPU last als bei nVidia. Auch hier hilft das bei AMD deutlich mehr als bei nVidia.

Im Endeffekt helfen gerade bei AMD die LL APIs die schlechte Treiebrarbeit auszugleichen. AMD gibt also die eigene Arbeit an die SPieleenwtickler ab, nVidia Karten sind immer schon gut ausgelastet, da gibt es eben nicht viel mehr rauszuholen.
Und wie schon gesagt, wenn man sich das Endergebnis anschaut. Hilft das alles höchstens AMD zu einen gleichstand oder einen Vorteil zu niedrig getakteten nVidia Stock Karten. Quantum break lasse ich mal als Außnahme außen vor. Die anderen Titel zeigen eine andere Tendenz.

[Schaffe89]

Was ist da drann?

http://www.overclock.net/t/1605674/computerbase-de-doom-vulkan-benchmarked/220#post_25351958

Wenn das stimmt, wäre das natürlich für Nvidia blamabel.

[dargo]

Auch 4 Jahre alte Kepler Karten wie z.B. die GTX 670 profitieren massiv unter Vulkan im CPU limit. Und jetzt?

Nix und jetzt... gegenüber dem grützigen NV-Treiber in OpenGL stimmt das soweit. Dummerweise verliert Kepler ~25-37% im GPU-Limit bei Vulkan gegenüber OpenGL, also nicht wirklich praktikabel nutzbar. Ob sich das bessert müssen wir abwarten.


Und warum ist die Fury kaum langsamer als die Fury X? Weil sie ihre dicke Rechenleistung wegen des ineffizienten Designs nicht auf die Straße bekommt.

Korrekt... unter high-level sowieso nicht. Unter low level wirds besser, aber imho nicht gut genug (dafür kommt ja Vega). Obs in Zukunft besser wird muss sich erst zeigen. Ich fände eine Fury X mit 1,2Ghz und 3584SPs besser als die jetzige Fury X. Aber was willst du machen wenn solche Taktraten nicht erreicht werden? Stromverbrauch schießt dir auch irgendwann durch die Decke. Für die fetten 4096SPs muss das komplette Design verändert werden wie der CP etc. Und schon sind wir wieder bei Vega mit zusätzlichen Vorteilen der kleineren Fertigung + mehr HBM Speicher.


Auf der einen Seite kommen bei dir permanent Jubelarien auf LL APIs (teh future) und dann verkennst du, dass gerade unter so einer API der Abstand zwischen Fury und Fury X nochmal steigen wird, da einfach die Hardware besser ausgenutzt werden kann. Verstehe ich nicht. :confused:

Ich vergleiche hier keine Fury vs. Fury X sondern Fury Nitro vs. Fury X. Beide takten mit 1050Mhz. Du kannst mir gerne @low level zeigen wo die Fury X 14% schneller als die Fury Nitro ist. Denn genau das ist der Unterschied bei der theoretischen Alu-Leistung zwischen den Beiden. Mehr als 0-5% wird da nicht durchschlagen. Aber ich lasse mich gerne eines besseren belehren.

[VooDoo7mx]

Ich denke es gibt eine Tendenz:

http://up.picr.de/26233786mx.jpg

Ich denke mal du hast keien Ahnung.

Schon gesehen, dass unter 3840x2160 nVidia Karten vom Wechsel auf Open GL zu vulkan fps verlieren?
Vergleich mal Dota 2 3840x2160 nVidia Open GL vs AMD Vulkan. Da ahst du wieder das alte Bild. Und auch hier gewinnt AMD gut durch Vulkan % dazu, da einfach der Open GL Treiber Schrott ist.

Was ist da drann?

http://www.overclock.net/t/1605674/computerbase-de-doom-vulkan-benchmarked/220#post_25351958

Wenn das stimmt, wäre das natürlich für Nvidia blamabel.

Ironie?

Stock 1070 10% vor Fury X mit Async On.

[gedi]

Hör mir doch bitte auf mit OGL - die API ist de facto tot! Und was bitte interessieren irgendwelche Umstände diesbezüglich?

[mkh79]

Ich denke es gibt eine Tendenz:

http://up.picr.de/26233786mx.jpg
Schön, dass AMD Hardware so gut mit der Vulkan API läuft :smile:
Unter OpenGL hat man sich da echt manchmal Sorgen gemacht, aber das scheint man mit Vulkan endlich vergessen zu können. Freut mich echt, wo es da mit der Entwicklung hin geht :up:

[Kartenlehrling]

Das die gtx780ti die gtx980 schlägt ist aber auch seltsam, schöne an Dota2 ist das man Replays zum Testen nehmen kann.
Damit immer reproduzierbar.

[-/\-CruNcher-/\-]

Wieso ist das merkwürdig in dem test geht es weniger um zusätze im Featureset die bei Maxwell genutzt werden könnten als um die RAW Power.

[dargo]

Weil bisher kein Spiel so ein Bild zeigt. ;) Ich war noch nie ein Freund direkter Vergleiche der reinen Shaderpower über verschiedene Architekturen.

[-/\-CruNcher-/\-]

Dota 2 brauch jetzt nun nicht wirklich irgendwelche spezielen Optimierungen als ISO Moba, aber du hast schon recht in einem komplexen Renderablauf sieht das pro Frame anders aus :D

Nur Hypen ja momentan immer mehr die non ISO Mobas da wird alles dann wiederum Komplexer :D

[just4FunTA]

Ich denke es gibt eine Tendenz:

http://up.picr.de/26233786mx.jpg

Hast du ein Link zu dem Benchmark?

[Gipsel]

Die Moderation macht sich diese Ansage zu eigen:

Achtung, Achtung, eine Durchsage:

Sie befinden sich im Technologie-Forum. Dort Unterhält man sich über Technologie. *duh*
Die auf der Durchreise befindlichen Hooligans mögen sich bitte zu den Ausgängen bewegen. Vielen Dank für Ihr Verständnis.

In einem Technologiethread haben weder Fanboy-Auseinandersetzungen noch die Erwägungen des Pro und Kontra von eventuellen Kaufentscheidungen etwas verloren.

[Achill]

Hast du ein Link zu dem Benchmark?

Ich quote mich mal ...

[..] 'phoronix.com' nur schon folgenden Test [..] (26. Juni): http://www.phoronix.com/scan.php?page=article&item=amdgpu-rx480-linux&num=11

http://www.phoronix.net/image.php?id=2016&image=ttp_amdwin_2

http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=56722&stc=1&d=1468678085

[Fliwatut]

Gibt es eine Liste mit kommenden Spielen, die Vulkan unterstützen werden?

[VooDoo7mx]

Ich quote mich mal ...

Ja du scheinst auch nur Rosinen zu picken die dir ins Bild passen.

Hast du ein Link zu dem Benchmark?

Nein, aber ich: http://www.phoronix.com/scan.php?page=article&item=dota2-vulkan-redux&num=4

Wenn man sich nicht nur eine Grafik anschaut, sondern das gesamte Bild, kommt gleich ein anderes Ergebnis raus.
Die R9 Fury gewinnt da unter Vulkan nicht ganz 3% mehr FPS und nVidia Karten brechen stark ein.
Tatsächlich ist da eine GTX970 unter OpenGL schneller als eine Fury unter Vulkan.
Wenn man dann noch die andere Grafik hinzuzieht, sieht man das unter Vulkan eine GTX 1080 langsamer als einer GTX 980 unter Open GL ist. Das da was nicht stimmt, scheint keinen aufzufallen?

Ja daraus lässt sich eine eindeutige Tendenz erkennen. Das AMD mal wieder derbe abstinkt wegen ihren einfach nur unterirdisch schlechten Open GL Treiber.

Der Vulkan Modus in DOTA 2 ist übrigens auch nur Beta. Und allein dass da unter nVidia die fps so massiv einbrechen, lässt einfach nur auf eine schlechte implementierung schließen. Der Vulkan Modus wurde da im Mai hinzugefügt und bis heute nicht wirklich weiter entwickelt. Scheint also nicht so wichtig zu sein.

[Achill]

Ja du scheinst auch nur Rosinen zu picken die dir ins Bild passen.
[...]


Ich habe die aktuell zwei verfügbaren Vulkan-Tests für Linux verlinkt. Daten zu OpenGL und/oder wie gut OpenGL Treiber sind passen nicht in diesen Thread (schon Benchmark-Werte sind eigentlich OT).
=> Ist daher auch kein 'Rosinen picken' - ganz einfach.

[just4FunTA]

Ich quote mich mal ...

Ach ok das hatte ich übersehen. VooDoo7mx hat aber schon recht sieht man sich auch den openglbenchmark an ändert sich das Bild komplett. Das würde ich wirklich nicht nutzen um irgendwelche Tendenzen beurteilen zu wollen. Die 970 verliert ja 30fps von Opengl zu Vulkan, Vulkan wäre ja eine erbärmliche Entwicklung wenn der Benchmark repräsentativ für Vulkan wäre.

https://abload.de/img/opengl-vs-vulkanyjad2.png

[Unicous]

Du meinst, das wäre eine erbärmliche Entwicklung des Nvidia Vulkan-Treibers wenn DotA 2@Vulkan repräsentativ wäre.:wink:

Warum stellt hier eigentlich niemand die Frage nach dem Warum? Dass AMD hier besser abschneidet dürfte ja allen klar sein. Der OpenGL-Treiber ist traditionell einfach nicht performant und bis vor wenigen Jahren auch noch extrem buggy.

Warum aber verliert Nvidia bei Phoronix? Liegt es am Treiber, liegt es an Valve, liegt es an Vulkan?

Warum sollte es an Vulkan hängen, wenn Nvidia sogar zuletzt mit Doom geworben hat und unlängst zugegeben hat, dass sie keinen Game Ready Treiber für den Vulkan-Pfad haben.

Warum muss es immer am Entwickler oder an der API liegen, warum kann nicht auch mal Nvidia verkacken?

Und überhaupt... das ist mittlerweile fast 2 Monate her, seither gab es zig Patches und neue Treiber, woher wisst ihr überhaupt ob dieses "Bild" überhaupt noch aktuell ist?

Und warum zum Teufel vertraut ihr bei Tests auf Phoronix? Larabel haut am Tag zig "Artikel" raus, aber Qualität ist bei ihm Mangelware. Und eine Einschätzung geschweige denn ein Fazit gibt es bei ihm nicht er kratzt immer nur an der Kruste. Oberflächlichkeit ist bei ihm an der Tagesordnung im wahrsten Sinne des Wortes.

[dargo]

Warum muss es immer am Entwickler oder an der API liegen, warum kann nicht auch mal Nvidia verkacken?

Weil Nvidia Gott ist. :eek: ;)

[StefanV]

Und allein dass da unter nVidia die fps so massiv einbrechen, lässt einfach nur auf eine schlechte implementierung schließen. Der Vulkan Modus wurde da im Mai hinzugefügt und bis heute nicht wirklich weiter entwickelt. Scheint also nicht so wichtig zu sein.
Ja, nee, is klar.
Wenn etwas auf nVidia nicht so gut läuft, muss irgendwer anders das verbockt haben. Nur nVidia halt nicht.

Dir ist aber schon aufgefallen, dass die Pascal Architektur ziemlich rückständig ist und einige performance steigernde Features nur unzulänglich, wenn überhaupt, unterstützen?!

Vielleicht liegt das schlicht daran, dass das die Xte Aufwärmung vom G80 ist und das Design ein wenig ausgelutscht?!

Also hör auf, solch einen Unsinn zu behaupten, nur weil es dir gerade in den Kram passt.

[VooDoo7mx]

Du meinst, das wäre eine erbärmliche Entwicklung des Nvidia Vulkan-Treibers wenn DotA 2@Vulkan repräsentativ wäre.:wink:

Warum stellt hier eigentlich niemand die Frage nach dem Warum? Dass AMD hier besser abschneidet dürfte ja allen klar sein. Der OpenGL-Treiber ist traditionell einfach nicht performant und bis vor wenigen Jahren auch noch extrem buggy.

Warum aber verliert Nvidia bei Phoronix? Liegt es am Treiber, liegt es an Valve, liegt es an Vulkan?

Warum sollte es an Vulkan hängen, wenn Nvidia sogar zuletzt mit Doom geworben hat und unlängst zugegeben hat, dass sie keinen Game Ready Treiber für den Vulkan-Pfad haben.

Warum muss es immer am Entwickler oder an der API liegen, warum kann nicht auch mal Nvidia verkacken?

Und überhaupt... das ist mittlerweile fast 2 Monate her, seither gab es zig Patches und neue Treiber, woher wisst ihr überhaupt ob dieses "Bild" überhaupt noch aktuell ist?

Und warum zum Teufel vertraut ihr bei Tests auf Phoronix? Larabel haut am Tag zig "Artikel" raus, aber Qualität ist bei ihm Mangelware. Und eine Einschätzung geschweige denn ein Fazit gibt es bei ihm nicht er kratzt immer nur an der Kruste. Oberflächlichkeit ist bei ihm an der Tagesordnung im wahrsten Sinne des Wortes.

Jetzt mal langsam. Bevor du weiter hirgendwelchen Quark schreibst, wie das nVidias Vulkan Treiber schlecht ist, solltest du mal gganz in Ruhe durch atmen und mal überlegen, was eine LL API überhaupt ist. Du scheinst anscheinend keinen blassen Schimmer zu haben.

Bei einer LL API ist der Treiber nur noch eine hauchdünne Schicht und man programmiert direkt an der Hardware. Das heißt wenn von einer HL API wie Open GL auf eine LL API wie Vulkan, deutlich an FPS verloren geht, dann hat der Software Entwickler Mist gebaut und nur der.
Im schlimmsten Fall sollte bei Wechsel von Open GL auf Vulkan die Performance gleich bleiben.

Und DOTA 2 Benchmarks gibt es auch von anderen Seiten. Wie z.b. auch COmputerbase. Die zeigen alle das selbe Bild.

Und das ist genau der springende Punkt. Durch LL APIs steigt der Aufwand für Softwareentwickler deutlich an.
Er steigt noch mehr an, wenn man wirklich gute Ergebnisse erzielen will. Dann muss man nämlich den Code für jeden einzelnen GPU extra anpassen um das bestmögliche Ergebnis zu erreichen. Dass sind 1000de Mannstunden zusätzliche Arbeit. Selbst wenn man dies nur pro GPU Generation macht, ist der Aufwand enorm. Wenn man das nur pro GPU Hersteller macht, ist der Mehrwaufand immer noch deutlich höher, jedoch werden die erzielten Ergebnisse mit abnehmender Granularität immer schlechter.

Aber das wollen ja gerade die roten Boys nicht verstehen. Die denken, dass man bei der Software Entwicklung nur den LL API Knopf dücken muss und durch Zauberhand läuft das Spiel 50% auf der 5 Jahre alte Radeon Karte die man sich für luxuriöse 150€ mal gekauft hat. Und natürlich "können" nVidia Karten LL "nicht" und sind in Zukunft komplett aufgeschmissen. Was einfach nur absoluter Schwachsinn ist.

Bei teuren Produktionen werden LL APIs sicher ein wichtigen Stellenwert in Zukunft haben, da man mit Budgets von $100 Mio+ das sicher mit finanzieren kann. Es wird aber auch viele Studios geben, die einfach sich den Aufwand sparen oder sich das schlicht und ergreifend einfach nicht leisten können.
Dann kommen noch weitere Fragen hinzu, ob z.b. Engine X überhaupt für den Mehraufwand überhaupt profitiert. Auch nicht für jedes Spiel/Game Engine macht Async Compute sind. LL APIs sind nicht in jeden Fall die Zukunft.

Ja, nee, is klar.
Wenn etwas auf nVidia nicht so gut läuft, muss irgendwer anders das verbockt haben. Nur nVidia halt nicht.

Dir ist aber schon aufgefallen, dass die Pascal Architektur ziemlich rückständig ist und einige performance steigernde Features nur unzulänglich, wenn überhaupt, unterstützen?!

Vielleicht liegt das schlicht daran, dass das die Xte Aufwärmung vom G80 ist und das Design ein wenig ausgelutscht?!

Also hör auf, solch einen Unsinn zu behaupten, nur weil es dir gerade in den Kram passt.

Aua. Bitte mach das es aufhört.

[dargo]

Jetzt mal langsam. Bevor du weiter hirgendwelchen Quark schreibst, wie das nVidias Vulkan Treiber schlecht ist, solltest du mal gganz in Ruhe durch atmen und mal überlegen, was eine LL API überhaupt ist. Du scheinst anscheinend keinen blassen Schimmer zu haben.

Bei einer LL API ist der Treiber nur noch eine hauchdünne Schicht und man programmiert direkt an der Hardware. Das heißt wenn von einer HL API wie Open GL auf eine LL API wie Vulkan, deutlich an FPS verloren geht, dann hat der Software Entwickler Mist gebaut und nur der.

Da muss ich dich leider enttäuschen.

Support for:
Quantum Break™
Upto 35% faster performance using Quantum Break™ on Radeon™ R9 Fury X than with Radeon™ Software Crimson Edition 16.3.2.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=572175

Gears of War Ultimate Edition
Up to 60% on AMD Radeon™ R9 Fury X series vs AMD Radeon™ Software Crimson Edition 16.2.1
Up to 44% on AMD Radeon™ R9 380 series vs AMD Radeon™ Software Crimson Edition 16.2.1
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=571555

Ich frage mich wer hier keinen blassen Schimmer hat? Sooo "dünn" wie du dir das vorstellst ist die Schicht noch nicht. Bei high-level hatten wir halt ne Mauer. :D

[kruemelmonster]

Hör mir doch bitte auf mit OGL - die API ist de facto tot! Und was bitte interessieren irgendwelche Umstände diesbezüglich?

Andersrum wird ein Schuh draus, Vulkan macht noch in die Windeln. Und nur weil es grad sein erstes Wort rausbekommen hat ("DOOM") wird die Qualität des OpenGL Treibers nicht auf einmal unwichtig, offizielle Vulkan Patches für die gesamte Quake und Wolfenstein Reihe und das gute alte Prey wirds nicht geben.

[dargo]

Andersrum wird ein Schuh draus, Vulkan macht noch in die Windeln. Und nur weil es grad sein erstes Wort rausbekommen hat ("DOOM") wird die Qualität des OpenGL Treibers nicht auf einmal unwichtig, offizielle Vulkan Patches für die gesamte Quake und Wolfenstein Reihe und das gute alte Prey wirds nicht geben.
Jetzt mal ehrlich, du glaubst doch nicht wirklich, dass die Masse so alte Schinken noch interessieren oder? Lass mal die paar Nostalgiker außen vor. Das wäre auch nicht im Sinne vom Publisher, der will Verkäufe generieren und das geht nur mit neuen Spielen. Drei mal darfst du raten mit welcher API Wolfenstein 2 kommen wird.

PS: Wolfenstein ist zwar noch nicht so extrem alt, aber auch hier ist der Zug bereits abgefahren.

[iuno]

Warum stellt hier eigentlich niemand die Frage nach dem Warum?
Du nennst doch selbst genuegend Gruende, warum diese Frage sich nicht lohnt zu stellen ;p
Etwas OT jetzt, aber weil es gerade dazu passt: Michael hat vor kurzem begonnen, Cycles (Blender Renderer) zu vermessen, hat ganz offensichtlich die CPU rendern lassen, ohne was zu merken und titelt dann "Blender's AMDGPU-PRO OpenCL Performance Is Crazy Slow Compared To NVIDIA CUDA (https://phoronix.com/scan.php?page=news_item&px=Blender-Slow-OpenCL-AMDGPU)"
:facepalm:
Das sagt einfach wieder mal alles uber die Qualitaet seiner Tests und die Hingabe aus...

[SaschaW]

Das heißt wenn von einer HL API wie Open GL auf eine LL API wie Vulkan, deutlich an FPS verloren geht, dann hat der Software Entwickler Mist gebaut und nur der.

Als jemand der fast von Anfang an bei Vulkan mit dabei war und IHV-(und Platform)übergreifend entwickelt kann ich dieser Aussage nicht zustimmen.

Dafür gibt es auch bei einer LL API (die nicht so hauchdünn ist wir man es hätte machen können, es muss ja auch an Sicherheit des OS gedacht werden) noch genug Stellen an denen der Treiber was falsch machen kann. Egal ob bei einer bestimmten Kombination von Aufrufen oder z.B. der SPIR-V Reflection.

Genau wie bei OpenGL und Co. wird es auch mit den neuen LLs etwas dauern bis die Treiber mit allen Use-Cases zurechtkommen und Shader optimal übersetzen. Dauert dann halt nur vermutlich nicht so lange wie bei OpenGL.

[just4FunTA]

Du meinst, das wäre eine erbärmliche Entwicklung des Nvidia Vulkan-Treibers wenn DotA 2@Vulkan repräsentativ wäre.:wink:



Ich mein schon das was ich geschrieben habe, würden in Zukunft alle Spiele so performen auf Vulkan wie in diesem Dota2 Benchmark wäre Vulkan Müll.

Aber das bezweifle ich halt, mögliche Schuldige sehe ich hier in den Entwicklern, Nvidia aber auch das OS (Linux) kommt da in Frage.

Aber die Benchmarks finde ich auch unter Opengl etwas sonderbar wenn ich sehe das ne 970GTX 86FPS liefert und eine 1080GTX 99fps wundert mich das schon ein bissel..

[Foobar2001]

So Low Level ist es dann auch nicht. Es ist nicht so als haette man direkt Zugriff auf irgendwelche Hardware-Register. Das Speicher-Management und die Synchronisierung ist jetzt in der Hand der Applikation und es gibt keine dynamischen States mehr.

Man sagt dem Treiber einmal "Hier ist der gesamte Zustand der Render-Pipeline fuer diesen Draw-Call" und er kompiliert es zusammen. Das dauert auch ewig (100+ms manchmal). Das ist natuerlich komplett Treiber abhaenig wie gut das optimiert wird. Das ist eigentlich sogar eine dickere Schicht als frueher, weil es aggressivere Optimierungen zulaesst.

[SaschaW]

Das Speicher-Management und die Synchronisierung ist jetzt in der Hand der Applikation und es gibt keine dynamischen States mehr.

Das stimmt nicht ganz. Es gibt noch einige dynamische States für z.B. Viewports, Scissor, Depthbias, usw. (ein paar Kompromisse mussten gemacht werden).

Man muss aber beim Erzeugen des PSO angeben welche dynamischen States man verwenden will, so dass der Treiber zumindest vorgewarnt wird.

[Foobar2001]

Das ist mir bewusst. Kann man hier auch einmal nichts auch einfach mal unterschlagen um die Diskussion nicht in komplett irrelevante Bereiche abdriften zu lassen ohne das einer klugscheissen muss?

[N0Thing]

Kaum dynamischen States mehr anstatt keine, hätte den Zweck erfüllt. ;)

[Trap]

Das ist mir bewusst. Kann man hier auch einmal nichts auch einfach mal unterschlagen um die Diskussion nicht in komplett irrelevante Bereiche abdriften zu lassen ohne das einer klugscheissen muss?
Bevor die Doom-Vulkan AMD vs. Nvidia Horde aufgetaucht ist hat man sich hier über fundierte Einwände noch gefreut.

[Foobar2001]

Kaum dynamischen States mehr anstatt keine, hätte den Zweck erfüllt. ;)
Nicht wirklich. Die dynamischen States die es gibt sind irrelevant fuer die Optimierungen die ich angesprochen habe. Das verduennt nur die Aussage.

[Screemer]

Super, jetzt werden schon die Leute angeblafft, die seit Tag 0 mit Vulkan zu tun haben. Hoffentlich geht Sasha nicht bald den selben Weg, den Alphatier und Coda gegangen sind.

[N0Thing]

Nicht wirklich. Die dynamischen States die es gibt sind irrelevant fuer die Optimierungen die ich angesprochen habe. Das verduennt nur die Aussage.

Deine Aussage war ja offensichtlich falsch, von daher wäre eine verdünnte Aussage vielleicht die bessere Wahl gewesen, wenn du dich schon über Korrekturen aufregst, die du selber nur zu gerne bereit stellst. ;)

[Foobar2001]

Deine Aussage war ja offensichtlich falsch
War sie im Zusammenhang mit dieser Diskussion nicht. Die States die in Vulkan dynamisch sind, sind nicht performance relevant wenn man sie dynamisch setzt (einfache Register-Programmierung, kein Code-Aenderung etc.). Sonst waeren sie ganz schnell wieder aus der Spec geflogen.

Jetzt sind wir wieder genau dort wo nichts diskutiert wird, nur Grabenkaempfe.

[kruemelmonster]

Jetzt mal ehrlich, du glaubst doch nicht wirklich, dass die Masse so alte Schinken noch interessieren oder? Lass mal die paar Nostalgiker außen vor. Das wäre auch nicht im Sinne vom Publisher, der will Verkäufe generieren und das geht nur mit neuen Spielen. Drei mal darfst du raten mit welcher API Wolfenstein 2 kommen wird.

PS: Wolfenstein ist zwar noch nicht so extrem alt, aber auch hier ist der Zug bereits abgefahren.

Lese bitte im Kontext worauf ich geantwortet habe.

Und da dich "alte Schinken" wie üblich nicht interessieren kannst du als Gegenbeispiel zur angeblichen Unwichtigkeit von OpenGL auch die gesamte Steam Linux Libary nehmen.

Die mag dir evtl auch egal sein, aber du bist ja auch nicht der Nabel der Welt. ;)

[KiBa]

Funktioniert GSync mit Vulkan im Moment allgemein nicht oder ist das ein Problem von Doom?

[Foobar2001]

Funktioniert bei mir problemlos.

[blaidd]

Funktioniert bei mir problemlos.

Die Geforce-GPUs machen eh alle paar Frames einen Legacy-Flip unter Vulkan und laufen synchronisiert mit der Refreshrate des Monitors (ähnlich wie die Syncro über UWP, hängt vielleicht damit zusammen) Gsync oder nicht - daher gibt's bei 60-Hz-Displays auch immer wieder kleine Stocker ;). AMD-GPUs laufen frei. Ich hab da in der kommenden PCGH was zum Thema... :)

[fondness]

Die Geforce-GPUs machen eh alle paar Frames einen Legacy-Flip unter Vulkan und laufen synchronisiert mit der Refreshrate des Monitors (ähnlich wie die Syncro über UWP, hängt vielleicht damit zusammen) Gsync oder nicht - daher gibt's bei 60-Hz-Displays auch immer wieder kleine Stocker ;). AMD-GPUs laufen frei. Ich hab da in der kommenden PCGH was zum Thema... :)

Ahh, das erklärt die µRuckler, von denen viele Geforce-Nutzer unter Doom mit Vulkan berichten^^

[blaidd]

Ahh, das erklärt die µRuckler, von denen viele Geforce-Nutzer unter Doom mit Vulkan berichten^^

Genau so isses... :)

[Foobar2001]

Die Geforce-GPUs machen eh alle paar Frames einen Legacy-Flip unter Vulkan und laufen synchronisiert mit der Refreshrate des Monitors (ähnlich wie die Syncro über UWP, hängt vielleicht damit zusammen) Gsync oder nicht - daher gibt's bei 60-Hz-Displays auch immer wieder kleine Stocker ;). AMD-GPUs laufen frei. Ich hab da in der kommenden PCGH was zum Thema... :)
Kinderkrankheiten im Treiber wohl.

[KiBa]

Also bei mir kommen am Monitor 165Hz an in Doom, wenn ich GSync aktiviere. Die eigentliche Framerate liegt aber bei ca. 80 bis 100. Wenn die Framerate über der Refreshrate liegen sollte, sieht das dann natürlich so aus, als ob GSync funktioniert. Ist dann gleich zu VSync. Kann wirklich jemand bestätigen, dass das Gsync-Monitor-OSD synchron mit der fps-Anzeige zu Doom läuft bei niedrigen Frameraten? Ich habe hier alle Kombinationen von Sync-Einstellungen im Spiel und Treiber probiert, ohne Erfolg. Nach umschalten auf OpenGL gehts dann wieder.

[Foobar2001]

Ich wuerde einfach mit OpenGL spielen, so lange das nicht gefixt ist. Ist ja nicht so als waere es viel langsamer auf NVIDIA wenn man nicht im CPU-Limit ist.

[blaidd]

Ich check morgen mal Gsync, das könnte schon helfen, die Bildausgabe zu glätten. Momentan sieht das so aus (wobei ich mal nicht fies sein will, weil ich das für relativ leicht behebbar halte... und die synchronisierten Frames auch seperat nochmal aus den Messungen entferne und die theoretische Leistung angeben werde).

GTX 1070 Custom (~1.950 MHz) - 1440p@60

OGL: 124,2 Fps (keine Synchro)

Vulkan mit Synchro: 92,6 Fps (Triple Buffering + Framedrops - tatsächliche Framerate mit einem 60 Hz-Display)

Vulkan ohne Sync (Theoretisch, Frametimes händisch bereinigt): 124,7

Falls da Zweifel aufkommen:
https://youtu.be/27zvYGSGrng?t=232
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=56760&stc=1&d=1469047636

[y33H@]

Hast du PresentMon benutzt?

[blaidd]

Hast du PresentMon benutzt?

Japp, aktuelle Version. Zeigt auch schwarz auf weiß gesyncte und gedroppte Frames bei Nvidia unter Vulkan (OGL und AMD sind nicht betroffen). Das dürfte dann auch die Stocker (Framedrops) und die tendenziell recht ausgeprägte Eingabelatenz (Buffering) unter Vulkan erklären, über die sich alle beschweren ;)

EDIT:
Also bei mir kommen am Monitor 165Hz an in Doom, wenn ich GSync aktiviere. Die eigentliche Framerate liegt aber bei ca. 80 bis 100. Wenn die Framerate über der Refreshrate liegen sollte, sieht das dann natürlich so aus, als ob GSync funktioniert. Ist dann gleich zu VSync. Kann wirklich jemand bestätigen, dass das Gsync-Monitor-OSD synchron mit der fps-Anzeige zu Doom läuft bei niedrigen Frameraten? Ich habe hier alle Kombinationen von Sync-Einstellungen im Spiel und Treiber probiert, ohne Erfolg. Nach umschalten auf OpenGL gehts dann wieder.

Bei 165 Hz (oder auch 120/144 Hz) gibt es sehr viele Möglichkeiten für einen Refresh. Das dürfte mit so einem Display tatsächlich auch kaum wahrnehmbar sein - Gsync muss man da eventuell auch noch mal gesondert betrachten. 60 Hz mit einer Nvidia @Vulkan dagegen fühlen sich ziemlich unsauber an (was sich auch mit Messungen belegen lässt - Tearing gibt's btw auch keins, was einen schon mal misstrauisch werden lassen sollte). Das kannst du aber natürlich auch selbst ausprobieren, indem du das Display auf 60 Hz festlegst (und vielleicht Gsync deaktivierst)...

Und ja: Nvidia arbeitet dran. Auch ein Grund, weshalb ich da momentan sowas wie Gnade vor Recht einräume ;) - Im Ernst: sollte ein einfacher Fix sein, aber ich kann halt nur das Ist messen, nicht das Wird-Sein. Das nochmal gesondert zu betrachten und die Frametimes zu säubern ist aber auch nur fair: Bei den ersten Hitman-Benchmarks unter DX12 bin ich für AMD auch (zeitraubende) Umwege gegangen, um die GPUs von dem 60-Fps-Lock zu befreien...

[iuno]

Diese Frametimes :ugly:
So wie das aussieht macht das aber natuerlich auch komplett die Performance kaputt. Wenn das behoben ist, sollten auch die avg. FPS steigen und Nvidianer koennen sich beruhigen ;p

Woran liegt diese forced-sync denn jetzt eigentlich? An Windows 10 oder dem Nvidia Treiber? Mit Windows 7 mal getestet?

[blaidd]

Diese Frametimes :ugly:
So wie das aussieht macht das aber natuerlich auch komplett die Performance kaputt. Wenn das behoben ist, sollten auch die avg. FPS steigen und Nvidianer koennen sich beruhigen ;p

Woran liegt diese forced-sync denn jetzt eigentlich? An Windows 10 oder dem Nvidia Treiber? Mit Windows 7 mal getestet?

Grad bei einem eigentlich so brutal geschmeidig und flüssig laufendem Titel wie Doom versaut das wirklich ziemlich heftig die Performance. Bei einem Sync grätscht laut Presentmon immer DXGI dazwischen, weshalb ich tendenziell Win 10 bzw. WDDM 2.0 in Verdacht habe - belegen kann ich das aber nicht und auch wenn ich persönlich nicht unbedingt ein Freund von Win 10 und Microsofts momentaner Marketing-Strategie bin, kann ich nicht mit gutem Gewissen behaupten, dass das Problem daher rührt. Für einen Vergleich mit Win 7 habe ich momentan auch nicht das zeitliche Budget, das wäre aber sicher mal interessant (wie überhaupt mal Win 7 vs Win 10 unter Vulkan)

[Foobar2001]

AMD laeuft problemlos, das muss der NVIDIA-Treiber sein.

[iuno]

Ja, ist natuerlich verstaendlich. Der Vergleich waere aber in der Tat mal interessant ;)
Der Linux-Vergleich faellt ja (dank DRM auch mit WINE) leider flach, ausser Bethesda entscheidet sich noch um.

@Foobar2001: es ist nicht auszuschliessen, dass der AMD Treiber einen Hack vornimmt, um irgendwo erzwungene Sync abzuschalten

[Foobar2001]

Es ist auszuschliessen. Die API hat alle Modi:
VK_PRESENT_MODE_FIFO_KHR - V-sync on
VK_PRESENT_MODE_FIFO_RELAXED_KHR - Adaptive V-sync
VK_PRESENT_MODE_IMMEDIATE_KHR = V-sync off
VK_PRESENT_MODE_MAILBOX_KHR = Fast sync

[blaidd]

Es ist auszuschliessen. Die API hat alle Modi:
VK_PRESENT_MODE_FIFO_KHR - V-sync on
VK_PRESENT_MODE_FIFO_RELAXED_KHR - Adaptive V-sync
VK_PRESENT_MODE_IMMEDIATE_KHR = V-sync off
VK_PRESENT_MODE_MAILBOX_KHR = Fast sync

Es könnte immer noch Windows 10 bzw. Microsofts tolle Display-Engine sein, wenn der Nvidia-Treiber vor der Bildausgabe erst noch um Erlaubnis fragen muss, wie das anfangs bei DX12 der Fall gewesen ist. Dann schmeißt Win 10 alle Frames weg, die irgendwie nicht ins Bild passen (was mich dieser DXGI-Vermerk ein wenig schwanen lässt).... In diesem Fall müsste sich Nvidia da wohl ähnlich wie AMD noch drumherum hacken (wobei das alles sehr spekulativ sowie ohne Beweiß oder Gewähr ist und ausdrücklich nicht für bare Münze genommen werden sollte).

[Foobar2001]

Windows 7 und 10 unterstuetzen beide einen Vollbild-Modus mit direktem flipping ohne Compositor.
In OpenGL aktivieren das die Treiber wenn sie merken, dass die App im Vollbild ist, bei Vulkan im Moment nur AMD. Das ist alles.

Btw. die swap chain ist eine Extension in Vulkan. Falls es da wirklich inhaerente Probleme gibt, dann kann man immer noch eine speziell fuer Windows anbieten, die die Probleme nicht hat :)

[blaidd]

Btw. die swap chain ist eine Extension in Vulkan. Falls es da wirklich inhaerente Probleme gibt, dann kann man immer noch eine speziell fuer Windows anbieten, die die Probleme nicht hat :)

Grade Vulkan sollte sich schon irgendwie um microsoft'sche Unsinnigkeiten herumdrücken können - ich hab da wie angedeutet kaum Zweifel dran ;)

Und Doom läuft ja auch unter OGL schon brachial gut auf Nvidia-GPUs, zu Meckern gibt's da wirklich nicht viel - ich bin immer und immer wieder einfach nur begeistert (hab ja grad selbst eine GTX 980 OC verbaut ;) )- aber dieser Performance-Anstieg bei AMD mit Vulkan ist auch nicht zu verachten und macht mir einfach Freude - da sind dann auch ein paar Überstunden zu verschmerzen...

Und im CPU-Limit oder mit einem prinzipell lahmen 8-Thread-AMD-FX hab ich noch gar nicht messen können (war der Plan, aber zeitlich vor der Heftabgabe einfach nicht mehr umsetzbar... kommt, wenn ich kann ;))

[dargo]

Diese Frametimes :ugly:
So wie das aussieht macht das aber natuerlich auch komplett die Performance kaputt. Wenn das behoben ist, sollten auch die avg. FPS steigen und Nvidianer koennen sich beruhigen ;p

Das erklärt dann einiges. Wenn das gefixt ist sollte NV zumindest nicht langsamer unter Vulkan sein als OpenGL.


@Foobar2001: es ist nicht auszuschliessen, dass der AMD Treiber einen Hack vornimmt, um irgendwo erzwungene Sync abzuschalten
AMD und Hack? Das wäre mal was ganz Neues. :tongue:


Und im CPU-Limit oder mit einem prinzipell lahmen 8-Thread-AMD-FX hab ich noch gar nicht messen können (war der Plan, aber zeitlich vor der Heftabgabe einfach nicht mehr umsetzbar... kommt, wenn ich kann ;))
Vorlagen was Szenenwahl angeht gibts hier genug in diesem Thread. ;)

[SaschaW]

Axel Gneiting (aka Coda) hat seinen Vulkan-Port für Quake veröffentlicht: https://github.com/Novum/vkQuake

Mal schauen ob ich das auch für Android auf meinem Shield ans Laufen bekomme ;)

[blaidd]

Axel Gneiting (aka Coda) hat seinen Vulkan-Port für Quake veröffentlicht: https://github.com/Novum/vkQuake

Mal schauen ob ich das auch für Android auf meinem Shield ans Laufen bekomme ;)

Goil! :)

[dargo]

Axel Gneiting (aka Coda) hat seinen Vulkan-Port für Quake veröffentlicht: https://github.com/Novum/vkQuake

Mal schauen ob ich das auch für Android auf meinem Shield ans Laufen bekomme ;)
Löl? Das wird kruemelmonster aber gar nicht gefallen. ;)

[fondness]

Es werden noch einige heute noch unangekündigte Vulkan-Spiele folgen. Ich würde die Hoffnung nicht aufgeben, dass Vulkan DX12 verdrängt. Das open-source-Argument ist ein verdammt gutes für viele Entwickler.

[Hübie]

Ich hätte zumindest nichts dagegen. :) Hat schon jemand Quake kompiliert?

@foobar2001: Nutzt Doom Fast-Sync? Kann man das irgendwie aktivieren?

[SaschaW]

Ich hätte zumindest nichts dagegen. :) Hat schon jemand Quake kompiliert?

Ja, ich. Geht mit einem aktuellen Visual Studio out-of-the-box. Wenn ich etwas Zeit finde will ich den Port um Android-Untersützung erweitern.

[Hübie]

Und ich hammel hab neulich erst VS auf der Zockerkiste deinstalliert:| Na ich probier's mal auf meinem Notebook. Kompiliert der die exe mit? War Quake nicht vollständig Open Source?

[Ganon]

Läuft auch unter Linux mit einer NVidia GTX 770 gut. Kann es gerade nicht mit Haswell testen, aber da ist Vulkan eh noch nicht fertig.

[Nightspider]

Lässt sich der CPU Overhead durch Async Compute eigentlich stärker reduzieren als ohne?

Ich frage mich das gerade nur weil ja in Zukunft auch wieder Games kommen werden die extrem viel CPU Leistung brauchen (Star Citizen) und frage mich gerade ob die ACEs dort zusätzliche Vorteile bringen könnten, also rein CPU seitig.

[Birdman]

Async Compute hat keinerlei Auswirkungen auf den CPU Overhead.

[iuno]

Hohe CPU Last aber im Uebrigen genausowenig. Ob AC aber helfen kann, die CPU zu entlasten, bleibt abzuwarten.
Es ist denkbar, dass durch AC z.B. mehr Physik auf der GPU laeuft statt auf der CPU aber solche Designentscheidungen werden bestimmt frueh in der Entwicklung, bei einem reinen nex-gen Spiel und eher nicht bei spaeten Portierungen getroffen werden. Ob das jemals Auswirkung hat muessen wir abwarten

[Lurtz]

Es werden noch einige heute noch unangekündigte Vulkan-Spiele folgen. Ich würde die Hoffnung nicht aufgeben, dass Vulkan DX12 verdrängt. Das open-source-Argument ist ein verdammt gutes für viele Entwickler.
Seit wann interessieren sich (AAA)-Entwickler für OpenSource?

[deekey777]

Seit wann interessieren sich (AAA)-Entwickler für OpenSource?

Bullet Physics wurde in GTA IV/V und RDR eingesetzt.

[captain_drink]

Die OS-Agnostizität ist für Entwickler bei Vulkan sicherlich das interessanteste Merkmal.

[Foobar2001]

Seit wann interessieren sich (AAA)-Entwickler für OpenSource?
Vulkan ist nicht Open Source - zumindest nicht die Treiber. Es ist ein offener Standard. Andere Baustelle.

Was Open Source ist sind die Validation Layer und Debug-Tools und es ist schon ziemlich cool wenn man den ganzen Code im Debugger hat dafuer und im Notfall auch was beheben kann. Wenn bei Microsofts Tools was nicht funktioniert, dann wird's vielleicht mal in drei Monaten behoben. Vielleicht.

Mal abgesehen davon, dass RenderDoc meiner Meinung nach der beste Grafik-Debugger ist und im Moment gibt's dort nur Vulkan und kein DX12.

[StefanV]

Seit wann interessieren sich (AAA)-Entwickler für OpenSource?
Seit sie den Code von diversen Closed Source Projekten nicht einsehen können, interessieren sie sich mehr für Dinge, wo sie den (Beispiel) Code sich anschauen können...

[Screemer]

Da du sicherlich auf die "Blackbox" gameworkselemente anspielst, sollte man vielleicht anmerken, dass du überhaupt nicht wissen kannst ob nv nicht die Sourcen der gameworkselemente vorzeigt, wenn man ne entsprechende Lizenz hat und ein nda unterzeichnet. Anpassen wird wohl eher schwierig aber seinen Code könnte man wohl darauf abstimmen. Die Konkurrenz bleibt so auch außen vor. Btw. Ich bin keine Freund von gameworks.

[Foobar2001]

Ich bin mir ziemlich sicher, dass Gameworks-Titel den Code bekommen. Das ist praktisch notwendig um es zu integrieren.

[Kriton]

Super, jetzt werden schon die Leute angeblafft, die seit Tag 0 mit Vulkan zu tun haben. Hoffentlich geht Sasha nicht bald den selben Weg, den Alphatier und Coda gegangen sind.

Vergiss Demiurg nicht.

[Disco_STFU]

Nach Doom mit Vulkan: id Software will Asynchronous Compute exzessiv weiternutzen


http://www.pcgameshardware.de/Doom-2016-Spiel-56369/News/Doom-Vulkan-Asynchronous-Compute-1202335/

[Kartenlehrling]

Naja id Soft ist nur ein Studio von ZeniMax Media (https://www.zenimax.com/studios), toll wär wenn das "ganze" Unternehmen sich für Vulkan + Asynchronous Compute entscheidet.

[DanMan]

http://www.pcgameshardware.de/Doom-2016-Spiel-56369/News/Doom-Vulkan-Asynchronous-Compute-1202335/
...wären ja auch blöd, wenn sie es nicht tun würden... Sowas ist doch kein Artikel wert....

[deekey777]

...wären ja auch blöd, wenn sie es nicht tun würden... Sowas ist doch kein Artikel wert....

Natürlich ist es bei einer werbefinanzierten Webseite einen Artikel wert.

Zum Thema selbst:
Wo will id software AC noch einsetzen? Da gbt es aktuell nur ein anegkündigtes Quake-Projekt. Ist das eine versteckte Akündigung weiterer Spiele im Zenimax-Imperium?

[dildo4u]

Vermutlich meinen sie das näste Wolfenstein.

http://www.polygon.com/e3/2016/6/13/11917734/bethesda-the-new-colossus-tease-wolfenstein

[SaschaW]

Open-Source Vulkan C++ API: https://github.com/KhronosGroup/Vulkan-Hpp

Wurde von NVIDIAs vkCPP übernommen und ist damit jetzt ein offizielles Khronos Produkt :)

Interessant für jeden der Vulkan mit C++ nutzt und die C-Aufrufe und Structs nicht selber kapseln will.

Wer das in Aktion sehen will: Brad Davis hat meine Demos schon vor einiger Zeit geforkt und auf vkCpp umgebaut, den Fork findet man hier (https://github.com/jherico/Vulkan).

[Chris Lux]

Open-Source Vulkan C++ API: https://github.com/KhronosGroup/Vulkan-Hpp

Wurde von NVIDIAs vkCPP übernommen und ist damit jetzt ein offizielles Khronos Produkt :)

Interessant für jeden der Vulkan mit C++ nutzt und die C-Aufrufe und Structs nicht selber kapseln will.

Wer das in Aktion sehen will: Brad Davis hat meine Demos schon vor einiger Zeit geforkt und auf vkCpp umgebaut, den Fork findet man hier (https://github.com/jherico/Vulkan).
Es wäre sehr gut solche Links im ersten Posting zu sammeln. Das erleichtert zukünftige Suchen (via der mäßigen Suche hier :/).

[SaschaW]

https://github.com/vinjn/awesome-vulkan ;)

[Kriton]

Natürlich ist es bei einer werbefinanzierten Webseite einen Artikel wert.

Zum Thema selbst:
Wo will id software AC noch einsetzen? Da gbt es aktuell nur ein anegkündigtes Quake-Projekt. Ist das eine versteckte Akündigung weiterer Spiele im Zenimax-Imperium?

Sie haben doch schon mal gesagt, dass sie an anderen Sachen (http://www.4players.de/4players.php/spielinfonews/Allgemein/8636/2156403/Bethesda_Softworks-Drei_unangekuendigte_langfristige_Projekte_in_Entwicklung_mehr_Mobile-Titel_aufgrund_des_Erfolgs_von_Fallout_Shelter.html) arbeiten.

[HOT]

Naja id Soft ist nur ein Studio von ZeniMax Media (https://www.zenimax.com/studios), toll wär wenn das "ganze" Unternehmen sich für Vulkan + Asynchronous Compute entscheidet.
Da wird schon ordentlich Technik-transfer stattfinden. In FO4 hat man das jetzt noch nicht bemerkt, das versteh ich, da Synergien hinzubekommen wird dauern. Die übrigen Studios haben ja schon id Tech5-Technik verwendet.

[dargo]

http://www.pcgameshardware.de/Doom-2016-Spiel-56369/News/Doom-Vulkan-Asynchronous-Compute-1202335/
Demnach sehe man Asynchronous Compute als eine Kerneigenschaft von Low-Level-APIs an, von der man glaubt, dass sie viele weitere Entwickler in Zukunft nutzen werden. Man selbst habe jetzt erste Erfahrungen damit gemacht und wolle das Feature künftig exzessiver in Spielen auf Basis der id-Tech-6-Engine nutzen. Asynchronous Compute wird momentan ausschließlich auf Radeons eingesetzt, sowohl in der PC- als auch in den Konsolen-Versionen. Die Playstation 4 und Xbox One sollen die Bilder durch AC 3 bis 5 ms schneller berechnen können. Bei einem Target von 16,67' ms (60 Fps) entspricht das einer Fps-Verbesserung von rund 25 bis 45 Prozent oder anders gesagt, werden nun an Stellen, die vorher mit 60 Fps liefen, 75 bis 87 Fps gerendert.
Tja... und die bis zu 46% aus der AMD-Folie wollte keiner glauben. ;)

[Chris Lux]

https://github.com/vinjn/awesome-vulkan ;)Thx ;)

[KiBa]

Open-Source Vulkan C++ API: https://github.com/KhronosGroup/Vulkan-Hpp

Wurde von NVIDIAs vkCPP übernommen und ist damit jetzt ein offizielles Khronos Produkt :)[/url].
Heißt das, Vulkan-Hpp und vkCPP sind identisch?
Ich hatte mal ein wenig mit vkCPP rumgespielt, was schon mal ein Schritt in die richtige Richtung ist. Leider fehlen richtige Handle-Wrapper mit Destructors und damit die mögliche Nutzung von RAII.

[Foobar2001]

Nennt mich alt, aber das das Interface C ist, ist das kleinste Problem wenn man es mit Vulkan zu tun hat.

Ich wuerde mich nicht von einem Wrapper abhaengig machen, nur um ein kleines bisschen weniger Code schreiben zu muessen.

[Ganon]

Nennt mich alt, aber das das Interface C ist, ist das kleinste Problem wenn man es mit Vulkan zu tun hat.

Ich wuerde mich nicht von einem Wrapper abhaengig machen, nur um ein kleines bisschen weniger Code schreiben zu muessen.

Es richtet sich eher an Leute, die dann eh einen eigenen C++ Wrapper schreiben würden. Außerdem ist Grafik-API Code jetzt nicht unbedingt Code den man über Jahre (unverändert) durch verschiedene Iterationen der Anwendung schleifen wird. Von daher ist eine Abhängigkeit an einen offiziellen Wrapper auch nicht so wild.

[KiBa]

Nennt mich alt, aber das das Interface C ist, ist das kleinste Problem wenn man es mit Vulkan zu tun hat.

Ich wuerde mich nicht von einem Wrapper abhaengig machen, nur um ein kleines bisschen weniger Code schreiben zu muessen.
Es ist *ein* Problem und jeder vernünftige Programmierer wrappt da was herum. Der Code wird dadurch nicht nur etwas kleiner sondern auch deutlich les- und wartbarer.

[d2kx]

Viele dürften inzwischen die heutigen News zum Nintendo NX gelesen haben:

http://www.eurogamer.net/articles/2016-07-26-nx-is-a-portable-console-with-detachable-controllers

Ich denke, wenn man NVIDIA Tegra X1 (bzw. vermutlich im Endprodukt eher der nächste Tegra-Chip) + Gerüchte über eine Android-Basis, jedenfalls ursprünglich + Nintendos Beitritt zur Khronos Gruppe vor einigen Monaten zusammenzählt, wird es immer wahrscheinlicher, welche Grafik-API da kommen mag.

Weiterhin wird OpenGL 2016, welches morgen offiziell vorgestellt wird, wohl ARB_gl_spirv (https://www.opengl.org/registry/specs/ARB/gl_spirv.txt) unterstützen.

[blaidd]

Und ich hab morgen früh bezüglich Doom was für euch...

(Preemptive Clickbait: RX 480 OC schlägt GTX 1080 OC :tongue:)

[Screemer]

Hat nv das mit den gedroppten Frames immer noch nicht unter Kontrolle?

Clickbaiting nach heutigem Model wäre: Wir ließen eine 1080oc gegen eine rx 480 antreten, ihr könnt euch nicht vorstelle. Was dann passierte...

[blaidd]

Nö, ist definitiv ein Faktor - der auch die Performance GTX 1080 vs RX 480 total versaut.

Das "preemptive" bezieht sich auf meine aktuelle Headline (über die ich schlussendlich wenig Kontrolle habe): "Doom - Performance-Analyse unter der Vulkan-API mit Benchmarks und Frametimes" - Die ist ja aber auch total langweilig (ich geb mir da aber ehrlich gesagt auch kaum noch Mühe - die pack ich lieber in den eigentlichen Artikel; ist meines Wissens der erste, der sich damit konsequent auseinander setzt) und man könnte das Ganze natürlich auch viel aufregender formulieren, ohne dabei die Wahrheit allzu sehr zu verbiegen - der oben genannte Umstand trifft tatsächlich zu - unter bestimmten (60-Hz-)Voraussetzungen ;)

[Hübie]

Viele dürften inzwischen die heutigen News zum Nintendo NX gelesen haben:

http://www.eurogamer.net/articles/2016-07-26-nx-is-a-portable-console-with-detachable-controllers

Ich denke, wenn man NVIDIA Tegra X1 (bzw. vermutlich im Endprodukt eher der nächste Tegra-Chip) + Gerüchte über eine Android-Basis, jedenfalls ursprünglich + Nintendos Beitritt zur Khronos Gruppe vor einigen Monaten zusammenzählt, wird es immer wahrscheinlicher, welche Grafik-API da kommen mag.

Weiterhin wird OpenGL 2016, welches morgen offiziell vorgestellt wird, wohl ARB_gl_spirv (https://www.opengl.org/registry/specs/ARB/gl_spirv.txt) unterstützen.

Vulkan ist hier naheliegend, ja.
Das mit SPIR-V hab ich nicht ganz gecheckt. Sind das Shader in "Klartext"? Sorry falls die Frage dumm ist :D Hab mir ja mal kompilierte Shader im Hex-Editor angesehen und da erkennt man ja Null Komma Nix. Kompiliert das jetzt noch der Treiber während der runtime?

[DanMan]

Vulkan ist hier naheliegend, ja.
Das mit SPIR-V hab ich nicht ganz gecheckt. Sind das Shader in "Klartext"? Sorry falls die Frage dumm ist :D Hab mir ja mal kompilierte Shader im Hex-Editor angesehen und da erkennt man ja Null Komma Nix. Kompiliert das jetzt noch der Treiber während der runtime?
Ne, sind vor-kompiliert (Binärcode).

https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html

[Hübie]

Okay das ist mir jetzt zu viel Text :D Wozu is das gut bzw. wo liegen die Vorteile? Kann es der Treiber nicht besser, da vom Hardwarehersteller progammiert?

[iuno]

Wozu is das gut bzw. wo liegen die Vorteile? Kann es der Treiber nicht besser, da vom Hardwarehersteller progammiert?
Wie der Name schon sagt, ist SPIR-V (IR = Intermediate Representation) kein Maschinencode, sondern eine Zwischensprache. Die Treiber generieren dann weiterhin den Maschinencode fuer die jeweiligen Architekturen, nur eben nicht mehr aus Quellcode, sondern aus der IR.
Man definiert also eine abstrakte Maschine, fuer die die IR quasi wie Maschinencode erstellt wird. Das Compiler Frontend (hier in die Anwendung gewandert) erstellt dann aus dem Quellcode die IR und das Backend (im Treiber) den Maschinencode fuer die echte Microarchitektur.
Falls du dich mit Java ein bisschen auskennst, ist es etwa vergleichbar mit dem Bytecode, der dort fuer die JVM generiert wird.
Das macht man zum einen natuerlich, um Arbeit zu sparen, so muss eben etwa nicht jeder Treiber ein Compiler Frontend bereitstellen. Der Code wird portabler und so bekommt man auch leichter neue Architekturen unterstuetzt (der Vendor muss "nur" noch das Backend liefern). Zum Anderen hat der Entwickler der Anwendung so natuerlich aber auch etwas mehr Einfluss.
Auch ein netter Nebeneffekt ist natuerlich, dass durch das "vorkompilieren" und das Ausliefern der Shader in IR statt Quellcode die Zeit, bis der Code ausgefuehrt werden kann, natuerlich auch entsprechend verkuerzt wird. Wenn der Treiber nur IR in Maschinencode uebersetzen muss geht das wesentlich schneller, als den Part des Frontends auch noch zu uebernehmen.

Prominentestes Beispiel ist wohl LLVM, zunaechst von Apple fuer C/Objective-C entworfen, die Infrastruktur wird aber inzwischen auch von ihnen fuer Swift und von vielen anderen Projekten genutzt, u.a. eben auch von Khoronos oder sogar von Windows in DX12.

http://www.aosabook.org/images/llvm/LLVMCompiler1.png

Man kann also relativ schoen Front- und Backends hinzufuegen, um nochmal Apple als Beispiel zu nennen: ihre recht neue Sprache Swift hat dann einfach ein neues Frontend bekommen, das den Code in die selbe IR uebersetzt wie zuvor ObjC. Die wird dann wiederum von ARM und x86 Backends fuer iOS und MacOS Geraete uebersetzt und es laeuft ;)

http://www.4gamer.net/games/033/G003329/20160317117/TN/017.jpg

http://streamcomputing.eu/wp-content/uploads/2015/03/spir-v_in_out-550x368.png


BTW: passt auch ein bisschen zum Thema: http://www.golem.de/news/tim-sweeney-microsoft-will-steam-zerstoeren-1607-122350.html
Sweeney labert immer nur gegen MS, tut aber nichts, obwohl er koennte. Irgenwie ist ihm aber wohl entgangen, wie die Prioritaeten in der Entwicklung so liegen. DX12 Support war in der UE4 schon weitaus frueher da als Vulkan :facepalm: Es koennte alles so einfach sein...

[Hübie]

Coole Erklärung. Dank dir. :up: Also ist es leichter zu portieren, shader werden schneller kompiliert und es liegt mehr Verantwortung beim Entwickler als beim Treiberteam.
Letzteres kann Vor- wie auch Nachteil sein. Bisher mussten Gamedevs ihren Code ja stets zu den IHVs geben und die sagen dann "Ja mach so oder so". Geben die Devs den Code nicht weiter dann muss das Treiberteam mühsam über Profiler den Renderprozess nachvollziehen und versuchen Schwachpunkte zu finden. Kann ziemlich aufwändig sein.
Andererseits: Wenn jetzt mehr beim Entwickler liegt kann der ja auch Ansätze nehmen die dem einen IHV besser schmecken als dem anderen und so könnte es zu mehr ungewöhnlichen Ausreißern nach oben oder unten kommen, oder? :|
Hab's nie so mit programmieren gehabt. :redface:

Edit: Im link von DanMan sieht man übrigens wie so ein shader dann aussieht.

[M4xw0lf]

Und ich hab morgen früh bezüglich Doom was für euch...

(Preemptive Clickbait: RX 480 OC schlägt GTX 1080 OC :tongue:)

Der Artikel ist online: http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/

Nvidia würde unter Vulkan also genauso gut laufen wie unter OGL, wenn nicht die eingebaute Synchronisation dazwischenpfuschen würde.

[Gorkon]

Also echt man ein fettes Dankeschön an PCGH und Marc (Golem) für die aufschlussreichsten Artikel zum Thema LL-API seit...ja seit überhaupt. Während die anderen Kollegen nur labern und spekulieren, macht ihr einfach :uup:

P.S.: Ich hoffe, nV fixt sein Vulkan-Problem schnell. Das ist ja wirklich unschön und vor allem super nervig für die User, die evtl. drauf angewiesen sind (Budget-CPU), trotz guter OpenGL-Leistung.

[Achill]

[..]
Letzteres kann Vor- wie auch Nachteil sein. Bisher mussten Gamedevs ihren Code ja stets zu den IHVs geben und die sagen dann "Ja mach so oder so".

Eigentlich müsste man nicht, es gibt ja eine API und Doku für diese - ist die API streng genug, dann kann man da auch nicht viel Quatsch/Verkehrt machen. AMD und NV stellen darüber hinaus ja auch Tools zur Analyse, ich denke da kann man auch viel 'sehen' was suboptimal läuft.
Zu einen IHV geht man m.M. nur, wenn man gar nicht weiter kommt (man darf die Zeit des Round-Trips / Slack nicht vergessen, wo man an dem Problem nicht weiter arbeiten kann) oder wenn man es vertraglich Vereinbart hat. :D


[..]
Geben die Devs den Code nicht weiter dann muss das Treiberteam mühsam über Profiler den Renderprozess nachvollziehen und versuchen Schwachpunkte zu finden. Kann ziemlich aufwändig sein.

Das hat sich ja jetzt mit den LL-APIs erledigt, weniger Treiber bedeutet weniger Black-Box-Layer bedeutet direkte Kontrolle beim Entwickler bedeutet WIR können besser das Blame-Game spielen. ;)


Andererseits: Wenn jetzt mehr beim Entwickler liegt kann der ja auch Ansätze nehmen die dem einen IHV besser schmecken als dem anderen und so könnte es zu mehr ungewöhnlichen Ausreißern nach oben oder unten kommen, oder? :|
Hab's nie so mit programmieren gehabt. :redface:

Das ging doch schon gut mit GW unter DX11/OpenGL und kleiner ...

[Hübie]

Und das Gameworks in seiner alten Form Schrott war / ist bestreitet hoffentlich niemand. Ich wünsche mir nach wie vor das beide IHV ihre dreckigen Pfoten von den Devs lassen sollten und denen einfach Resourcen zur Verfügung stellen müssen damit diese bestmögliche Performance und visuelle Qualität herausholen können.

[mkh79]

http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/

Super Test (y)
Auch die Vorgehensweise, die "gedropten" Frames mit einzukalkulieren, um zu sehen wo nvidia in Etwa stehen würde ohne Treiberprobleme.

[StefanV]

2 Dinge:
1. Schaut es im Video so aus, als ob der Philipp kurz davor lauthals loszulachen ist.
2. ähm, ist nicht soo toll, siehst dieses Video (https://www.youtube.com/watch?v=FYDA9Z4dvzs)...

[Hakim]

Hört sich ja zumindest so an das man es leicht Fixen könnte, wieso hat NVidia da noch nicht reagiert?

[dargo]

Der Artikel ist online: http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/

Nvidia würde unter Vulkan also genauso gut laufen wie unter OGL, wenn nicht die eingebaute Synchronisation dazwischenpfuschen würde.
Eine Sache finde ich merkwürdig dabei. NV hat doch gerade mit der GTX1080 @Vulkan mit 200fps geprahlt. Erstens sehe ich von den 200fps bei der PCGH nichts und zweitens ist echt niemandem dieses Problem bei der Bildausgabe aufgefallen? :|

Edit:
Ok... es hieß bis zu 200fps.
https://www.youtube.com/watch?v=okb3RVe2vbA

[Hakim]

Eine Sache finde ich merkwürdig dabei. NV hat doch gerade mit der GTX1080 @Vulkan mit 200fps geprahlt. Erstens sehe ich von den 200fps bei der PCGH nichts und zweitens ist echt niemandem dieses Problem bei der Bildausgabe aufgefallen? :|

Edit:
Ok... es hieß bis zu 200fps.
https://www.youtube.com/watch?v=okb3RVe2vbA

Ich glaube die meisten haben einfach weiter auf OpenGL gespielt nachdem sie gesehen haben das mit Vulkan die Fps runter geht, verständlicherweise. Oder auch gerade deswegen das es sich schwammiger angefühlt hat.

[blaidd]

Eine Sache finde ich merkwürdig dabei. NV hat doch gerade mit der GTX1080 @Vulkan mit 200fps geprahlt. Erstens sehe ich von den 200fps bei der PCGH nichts und zweitens ist echt niemandem dieses Problem bei der Bildausgabe aufgefallen? :|

Edit:
Ok... es hieß bis zu 200fps.
https://www.youtube.com/watch?v=okb3RVe2vbA

Unter 1080p kommt man hin und wieder kurz an die 200-Fps-Grenze. Das klappt mit einer R9 Fury X unter Vulkan aber praktisch genauso.

Das die Sync-erei nicht aufgefallen ist, finde ich auch merkwürdig - das ist eigentlich recht auffällig. Vielleicht bin ich aber auch einfach DX12- bzw. UWP-geschädigt und deshalb sensibilisiert...

[Butterfly]

Unter 1080p kommt man hin und wieder kurz an die 200-Fps-Grenze. Das klappt mit einer R9 Fury X unter Vulkan aber praktisch genauso.

Das die Sync-erei nicht aufgefallen ist, finde ich auch merkwürdig - das ist eigentlich recht auffällig. Vielleicht bin ich aber auch einfach DX12- bzw. UWP-geschädigt und deshalb sensibilisiert...
Naja 200FPS sind ja nicht immer notwendig, zumindest die 144FPS im Schnitt wäre schon mal sehr gut für 144Hz Monitore (sofern sie nativ Hz haben)!

Was habt ihr für eine VulkanRT Version?
Bei mir ist es 1.0.17.0 den Pfad dazu:

http://abload.de/img/vulkanrt_pathgksa8.jpg
Dort gibt es eine VulkanInfo.exe das spuckt sie bei mir aus im Anhang.

:wink:

[-/\-CruNcher-/\-]

Und ich hab morgen früh bezüglich Doom was für euch...

(Preemptive Clickbait: RX 480 OC schlägt GTX 1080 OC :tongue:)

Wundert wahrscheinlich nur dich ;)

Wie der Name schon sagt, ist SPIR-V (IR = Intermediate Representation) kein Maschinencode, sondern eine Zwischensprache. Die Treiber generieren dann weiterhin den Maschinencode fuer die jeweiligen Architekturen, nur eben nicht mehr aus Quellcode, sondern aus der IR.
Man definiert also eine abstrakte Maschine, fuer die die IR quasi wie Maschinencode erstellt wird. Das Compiler Frontend (hier in die Anwendung gewandert) erstellt dann aus dem Quellcode die IR und das Backend (im Treiber) den Maschinencode fuer die echte Microarchitektur.
Falls du dich mit Java ein bisschen auskennst, ist es etwa vergleichbar mit dem Bytecode, der dort fuer die JVM generiert wird.
Das macht man zum einen natuerlich, um Arbeit zu sparen, so muss eben etwa nicht jeder Treiber ein Compiler Frontend bereitstellen. Der Code wird portabler und so bekommt man auch leichter neue Architekturen unterstuetzt (der Vendor muss "nur" noch das Backend liefern). Zum Anderen hat der Entwickler der Anwendung so natuerlich aber auch etwas mehr Einfluss.
Auch ein netter Nebeneffekt ist natuerlich, dass durch das "vorkompilieren" und das Ausliefern der Shader in IR statt Quellcode die Zeit, bis der Code ausgefuehrt werden kann, natuerlich auch entsprechend verkuerzt wird. Wenn der Treiber nur IR in Maschinencode uebersetzen muss geht das wesentlich schneller, als den Part des Frontends auch noch zu uebernehmen.

Prominentestes Beispiel ist wohl LLVM, zunaechst von Apple fuer C/Objective-C entworfen, die Infrastruktur wird aber inzwischen auch von ihnen fuer Swift und von vielen anderen Projekten genutzt, u.a. eben auch von Khoronos oder sogar von Windows in DX12.

http://www.aosabook.org/images/llvm/LLVMCompiler1.png

Man kann also relativ schoen Front- und Backends hinzufuegen, um nochmal Apple als Beispiel zu nennen: ihre recht neue Sprache Swift hat dann einfach ein neues Frontend bekommen, das den Code in die selbe IR uebersetzt wie zuvor ObjC. Die wird dann wiederum von ARM und x86 Backends fuer iOS und MacOS Geraete uebersetzt und es laeuft ;)

http://www.4gamer.net/games/033/G003329/20160317117/TN/017.jpg

http://streamcomputing.eu/wp-content/uploads/2015/03/spir-v_in_out-550x368.png


BTW: passt auch ein bisschen zum Thema: http://www.golem.de/news/tim-sweeney-microsoft-will-steam-zerstoeren-1607-122350.html
Sweeney labert immer nur gegen MS, tut aber nichts, obwohl er koennte. Irgenwie ist ihm aber wohl entgangen, wie die Prioritaeten in der Entwicklung so liegen. DX12 Support war in der UE4 schon weitaus frueher da als Vulkan :facepalm: Es koennte alles so einfach sein...

Er ist einer der wenigen der die Klappe aufmacht das sind zwänge es geht nun mal um die erreichbare Userbase in dieser Kalkulation kannst du Microsoft nie einfach ignorieren da musst du wohl oder übel auch auf die Bühne rauf und alles gut reden wenn du deine Produkte verkaufen willst ;)


Hintenrum denkt er aber realistischer und weiss was mit UWP (WinRT) und Co abläuft das weiss jeder in der IT Branche nur wenige sagen dazu etwas.

Das immer mehr ihre Ökosysteme schliesen ist kein Geheimniss die ganze PC Platform leidet darunter.

Bei Sweeney spielen aber dazu natürlich auch eigene Ökonomische Interessen eine Rolle er hat ja selbst einen Content Marketplace wie Unity aufgebaut dem auch Crytek folgt, da macht er sich natürlich sehr viel gedanken wie das in Zukunft aussieht, wenn die Leute dann irgendwann total abhängig von X sind ist das niemals gut auch wenn sie nicht unbedingt merken wie das passiert ;)

Bin da etwas entspannter mehr Wettbewerb ist immer gut und Microsoft ist momentan in keiner guten Position vor allem gegen Google und Apple von daher sollte man sie erstmal aufholen lassen, vor allem wenn die Publisher dann im Fadenkreuz landen sehen wir als Kunden ja die Preisschlachten lossrollen :)

Allerdings muss man einfach sagen das Microsoft bei Spielen und deren Entwicklung noch ein absolutes Monopol hält und das ist in ihren neuen Bestrebungen doch sehr kritisch zu beugen, eigentlich geht es schon weit darüber hinaus was wir damals im IE case sahen.
Nur exestiert ja der Wettbewerb und der hat ja die Möglichkeiten zu agieren und das tut er ja auch teils mit Vulkan schon einleiten ;)
Alle wollen von DX 12 Profetieren aber die totale Abhängigkeit will doch niemand wirklich niemand nicht Nvidia nicht AMD nicht Apple selbst Intel nicht ;)

Gabe versucht ja alles das Final auch für Endkonsumenten zu brechen aber Microsoft eben auch alles das das nie passiert ;)

Eine der größten Probleme Microsofts wird Vulkan aber definitiv darstellen das pushed Gabe wo es nur geht und auch Sweeney und andere sind aufgesprungen so tatenlos wie du Sweeney hinstellst ist er nicht er ist sich dem ganzen sehr bewusst und reist deshalb ja auch die Klappe auf er brauch die API vorherschaft nicht mehr so zu fürchten er supportet zwar auch DX12, weil er ökonomisch eben noch dazu gezwungen ist aber er lässt auch durchblicken das er davon überhaupt nicht amused ist genauso wie er von dem geschlossenen Oculus Ökosystem Bestrebungen seitens Facebook nicht sehr amused war immerhin haben doch alle versprochen miteinander an der Revolution und ihrem Erfolg zu Arbeiten ;)

Einen Layer zu schaffen der andere Applikationen davon mittels DRM ausschliest ist ausschlieslich auf Monopol ausgerichtet deswegen war es letztendlich gut das er dort die Klappe als Celebrity aufgemacht hat egal ob es nur aus ökonomischen gründen der Fall war seiner eigenen Userbase gerecht zu werden oder aus moralischen, spielt dabei nicht so sehr eine Rolle ;)

Zugegeben seine Vulkan Bestrebungen innerhalb der Unreal Engine beziehen sich noch nur auf Mobile aber dabei muss und wird es sicherlich nicht bleiben nicht so wie er im Rage Mode momentan ist vielleicht fühlt er sich auch etwas selbst schuldig auf seine alten Tage es soweit kommen lassen zu haben als PC idealist und er selbst merkt immer mehr wie das "Personal" daraus verschwindet ;)

[Hübie]

Tim Sweeny und Unity? Da verwechselst du etwas. :D

@Butterfly: Gibt schon die 1.0.18.

[iuno]

Ist doch Unsinn. Sweeney bewegt sich genausowenig wie GabeN, obwohl beide eben die Moeglichkeit haetten, etwas zu tun. Da braucht man sich gar nichts schoen zu reden. Die stellen sich mal hin, reden ein bisschen dagegen, dann beteuert MS seine guten Absichten, rudert vielleicht vorerst ein-zwei Zuege zureuck und dann ist wieder alles gut.
Aber das betrifft ja nicht nur die Entwickler/Publisher, die Consumer lassen sich ja genauso von MS alles gefallen.

Ist hier allerdings auch voellig OT


edit: Ja, Sweeney gehoert natuerlich zu Epic (Unreal Engine), nicht zu Unity. War aber wohl nur ein Typo, unten steht es ja richtig. Unreal hat eben auch diesen Marketplace, das hat mit dem Thema aber sowieso sehr wenig zu tun. BTW: warum quotest du eigentlich alles, wenn du dich nur auf den letzten Absatz beziehst?

[blaidd]

Wenn ihr selbst mal mit Vulkan rumspielen wollt: Die Doom-Demo hat grade ein Vulkan-Update bekommen (http://steamcommunity.com/games/379720/announcements/detail/868451566755736093):)

[y33H@]

Vielleicht bin ich aber auch einfach DX12- bzw. UWP-geschädigt und deshalb sensibilisiert ...Quantum Break ruckelt eh immer und zeigt Ghosting :freak:

[d2kx]

OpenGL 2016 & Vulkan Update Livestream jetzt live:

http://livestream.com/khronosgroup/sig2016

[Hübie]

Wer redet da gerade? Ich erkenne kaum was. Geht nur bis 486p :( Danke für den Link :up:

[d2kx]

Vulkan Next

https://i.imgur.com/GwH0tBq.png

[Hübie]

Axel hat fertig. Interessanter Vortrag. Entgegen erster Aussagen wird AC in Doom doch bei weit mehr eingesetzt.

[Screemer]

Coda ist im Fernsehen ähhh Internetfernsehen. Sehr interessant. Schön zu wissen, dass der delay beim vulkanrenderer nicht an id sondern an den Treibern lag.

Gut finde ich auch, dass epic quasi nen fertigen Renderer in der Schublade hat.

[iuno]

Axel hat fertig. Interessanter Vortrag. Entgegen erster Aussagen wird AC in Doom doch bei weit mehr eingesetzt.
Z.B? Und warum haben sie dann erst gesagt, es wuerde nur fuer AA verwendet? :rolleyes:
Gibt es die Slides oder eine Aufzeichnung online?

[Hübie]

Ich weiß nicht mehr wer das war, aber war einfach nur ein tweet und die Korrektheit solcher ist... wiki-Niveau.

[Screemer]

Es ging imho darum, das mit einem der aamodi ac deaktiviert sein soll und man damit direkte vergleichbarkeit mit nv gegeben wäre. Hab ich schon immer bezweifelt.

Sehr interessant fand ich auch, dass Coda meinte es wäre noch nicht sicher ob wirkliche Parallelität auf nv Hardware möglich ist. Das muss sich mit neuen Treibern erst noch zeigen. Läuft wohl auf preemotion als Maximum hinaus. Oder hatte ich das falsch verstanden.

[Hübie]

Mit TSSAA ist AC aktiv, ansonsten wohl nicht, hieß es urpsrünglich.

Das mit dem Treiber war glaub ich ein kleiner Seitenhieb bzw. eine Anekdote. :D

[iuno]

OK habs gefunden: https://twitter.com/idSoftwareTiago/status/752590016988082180
Naja, das ist schon nicht irgendein Entwickler. Und man weiss auch, dass sowas eine gewisse Reichweite hat und etwa auch von den ueblichen Seiten uebernommen wird. Waere das kompletter Unsinn, haette man das schon revidiert.
Es wurde aber wohl tatsaechlich nur falsch verstanden. Inzwischen koennte AC durch ein Update auch sonst aktiv sein (s. erste Antwort)?

[Hübie]

Ah okay. Jetzt hats bei mir auch geklingelt. In Kombination mit TSSAA oder keinem AA wird AC genutzt. Sonst halt nicht. Und mit Updates kommen halt die anderen AA-Modi inkl. AC dazu. Edit: Zuvor hatte ich es so verstanden dass TSAA aus AC-Shader besteht X-D
Das mit dem NoAA hatte mich da nämlich verwirrt.

Tiago Sousa war ein Urgestein bei Crytek. Er ging vor Axel da weg.

[iuno]

Ja da warst du nicht der einzige. Hatte das auch anders im Kopf

[kruemelmonster]

Was habt ihr für eine VulkanRT Version?
Bei mir ist es 1.0.17.0

Ich spiel nicht an der Vulkan Installation herum sondern lasse die Runtime vom Treiber aktualisieren, und hab aktuell mit dem FW369.00 einen Ordner namens 1.0.11.1 drauf; Doom, AIDA64 und der GPU Caps Viewer lesen aber weiterhin die API Version 1.08 aus.

[Rancor]

Haha Nvidia sollte jetzt wirklich mal Ihren AC ( sofern es denn irgendetwas bringt ^^ ) Treiber bringen. Ich befürchte das wird ein Desaster für die Grünen. ^^ Naja irgendjemand wird meine 1070 noch kaufen wenn Vega da ist ^^

[Hübie]

Na ja am Ende des Tages ist mir wichtig was hinten herauskommt. Und da stehen - zumindest in Doom @Vulkan - beide Hersteller gut da. Und dieses Bild könnte in Zukunft sich angleichen wenn weniger DX11 und mehr Vulkan genutzt wird. Gegenüber DX12 hat man hier gleich den Vorteil der Plattformen und vor allem der Unabhängigkeit gegenüber Microsoft. Nun weiß ich zwar nicht wer schneller auf Devs reagiert, aber gestern suchte man ja den aktiven Dialog um Verbesserungen durch Erfahrungen einfließen zu lassen. Axel nannte da z.B. dass es tricky war die swap chain richtig aufzubauen. Da wird man sicher auch Zuhören und Veränderungen vornehmen.
Jetzt wo ich das Panel gestern geschaut habe wünsche ich mir mehr Dooms und weniger Quantum Breaks. :smile:

Edit: Vorher war es mir mehr oder weniger gleichgültig.

[Birdman]

Wayne AC?
Das ist doch mehr oder weniger nur ein Behelfslösung für Krüppel-GPUs, welche ohne dieses Konstrukt, die Compute Einheiten des Chips nicht gescheit auszulasten vermögen.

[M4xw0lf]

Wayne AC?
Das ist doch mehr oder weniger nur ein Behelfslösung für Krüppel-GPUs, welche ohne dieses Konstrukt, die Compute Einheiten des Chips nicht gescheit auszulasten vermögen.
Manch einer ärgert sich halt wenn die Krüppel-GPUs für den halben Preis dann schneller sind als seine glorious master race GPU.

[Locuza]

Wayne AC?
Das ist doch mehr oder weniger nur ein Behelfslösung für Krüppel-GPUs, welche ohne dieses Konstrukt, die Compute Einheiten des Chips nicht gescheit auszulasten vermögen.
Wenn du das so siehst dann hat jeder Prozessor eine Behelfslösung, um seinen verkrüppelten Beinen auf die Sprünge zu helfen.
Die Fähigkeit unabhängig Operationen auf den Compute-Units auszuführen um Idle-Times zu verkürzen ist prinzipiell eine gute Sache.
Maxwell ist schließlich auch nicht perfekt ausgelastet und würde davon profitieren, was genau bei Pascal auch verbessert wurde.

[Hübie]

Als ob man auf solche Phrasen eingehen möchte. Also wirklich. Ihr seid doch lang genug dabei um "don't feed the tr0ll" zu kennen. Ich dachte das wir wenigstens hier etwas frei von solchen Boxkämppfen wären. :(

@SaschaW: Hast du den Stream gestern geschaut? Was nimmst du davon mit und was schien am wichtigsten zu sein? :smile:

[Schnoesel]

Wenn ihr selbst mal mit Vulkan rumspielen wollt: Die Doom-Demo hat grade ein Vulkan-Update bekommen (http://steamcommunity.com/games/379720/announcements/detail/868451566755736093):)

Nice wie kann man sich mit Vulkan die FPS anzeigen lassen?

[Hübie]

Im Optionsmenü ganz unten mal schauen. Auf "Alptraum" bekommst du alles angezeigt.

[Schnoesel]

Wow also ich muss schon sagen beeindruckend. Bei UHD @ Ultra mit meinem System alles auf stock von min 35 FPS in Open GL zu min von 55 FPS in Vulkan. Wahrscheinlich profitiert meine CPU auch noch mal enorm.

[Hübie]

Geht mGPU eigentlich? Wie sind dann die Frametimes?

Edit: Ach, Sorry hab dich mit Achill verwechselt :D

[Rancor]

Gerade für Fiji ist DX12/Vulkan einfach richtig richtig gut.

[Hübie]

Jo, macht n richtigen Satz nach vorn. Schätze es kommt einer 980 Ti @1300-1350 gleich. Es gibt aber nach wie vor einige Stellen wo die Performance, zumindest hier bei mir, nicht zum Bildinhalt passt. Beispielsweise wenn man in der Argent-Anlage die Filter heraus reißt und dann den letzten Verteiler abgerissen hat. Schau ich mit dem Protagonisten drauf brechen die fps ziemlich weg (von 55-60 auf 42-45).

[dargo]

Grade für Fiji ist DX12/Vulkan einfach richtig richtig gut.
Och... die bis zu +~40% auf Grenada im GPU-Limit sind auch nicht übel. :D Bitte mehr davon. :naughty:

[Achill]

Geht mGPU eigentlich? Wie sind dann die Frametimes?

Edit: Ach, Sorry hab dich mit Achill verwechselt :D

Nein, noch gibt es kein Support für mGPU in Vulkan v1.0 (https://lunarg.com/faqs/vulkan-multiple-gpus-acceleration/) - zumindest kein DMA/Transfer/Copy zwischen den Karten. Man soll wohl fertige Bilder über den Host-Memory transferieren können - das wäre aber langsam, da GPU1 -> (CPU <-> RAM) -> GPU2...

Im Talk gestern ist es für Vulkan Next (v1.1?) schon angekündigt:

Vulkan Next

https://i.imgur.com/GwH0tBq.png

[Butterfly]

@Butterfly: Gibt schon die 1.0.18.
Es gab wohl ein Update, bin nicht jeden Tag online. :smile:
Ich spiel nicht an der Vulkan Installation herum sondern lasse die Runtime vom Treiber aktualisieren, und hab aktuell mit dem FW369.00 einen Ordner namens 1.0.11.1 drauf; Doom, AIDA64 und der GPU Caps Viewer lesen aber weiterhin die API Version 1.08 aus.
Rum spielen tu ich auch nicht, ist mir zufällig aufgefallen beim browsen mit dem Exlporer durch die Programm(x86) Ordner. :wink:

Wow also ich muss schon sagen beeindruckend. Bei UHD @ Ultra mit meinem System alles auf stock von min 35 FPS in Open GL zu min von 55 FPS in Vulkan. Wahrscheinlich profitiert meine CPU auch noch mal enorm.
Das kann schon sein, wobei das schwammige reagieren der Eingabe bei openGL deutlich auffällt wenn man alles auf Maximum einstellt.
Soweit ich weiß lassen sie ein Frame weg beim Render Prozess, das hilft gegen input lags.

Wie sehen bei dir die Albtraum Linien im Menü aus?
Grün = ok
Rot = Limit

openGL: http://abload.de/img/doom_20160717_openglwysdq.jpg
Vulkan: http://abload.de/img/doom_20160717_vulkancyspr.jpg

Geht mGPU eigentlich? Wie sind dann die Frametimes?

Edit: Ach, Sorry hab dich mit Achill verwechselt :D
Bisher nicht, evt. mit dem Update jetzt. :D

[Schnoesel]

Vulkan ist eher grün:

https://s31.postimg.org/6q7e641i3/DSC_0648.jpg

OpenGL eher rot

https://s32.postimg.org/48qi26551/DSC_0649.jpg

und das bei fast gleichen FPS.

Gott ist der Rand von meinem Bildschirm groß. Ich brauch echt langsam mal nen neuen. Wo sind sie die 4K DP 1.3 mit min. 100Hz?

[Achill]

Die 2016 SIGGRAPH Folien zu Vulkan (https://www.khronos.org/developers/library/2016-siggraph) sind online.

[Screemer]

heidewitzka. also doom mit vulkan heizt meiner 290 noch mehr ein als the division. hab heute das erste mal die 115°C bei vrm hinter mir gelassen. langsam mach ich mir sorgen :(

[SaschaW]

Die 2016 SIGGRAPH Folien zu Vulkan (https://www.khronos.org/developers/library/2016-siggraph) sind online.

Interessant sind v.a. die Videos zu den BOFs. Der BOF rund um Vulkan, OpenGL, OpenGL ES (http://livestream.com/khronosgroup/sig2016/videos/131128035) ist sehr interessant. Alex Gneiting erzählt was über Doom und Vulkan und Rolando Caloca Olivares über UE4.

[DanMan]

Interessant finde ich, dass an einem HLSL Converter für SPIRV gearbeitet wird, so dass man seine Shader von DX weiterverwenden kann. Das kann Vulkan einen ordentlichen Boost bei Devs geben.

[dargo]

heidewitzka. also doom mit vulkan heizt meiner 290 noch mehr ein als the division. hab heute das erste mal die 115°C bei vrm hinter mir gelassen. langsam mach ich mir sorgen :(
Welche 290 genau? Check mal dein PT, offenbar ist das zu hoch. Oder der Kühler taugt nichts. Null Probleme hier mit den beiden Games und der HiS R9 390 bei angenehmen ~1600RPM Lüfter.

[Ex3cut3r]

Wird wohl verstaubt sein? Und dann noch diese Ambient Temps draußen. Geh da mal ordentlich mit Druckluft ran.

MfG

[dildo4u]

Doom mit dem neuen Patch mit einer 970.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11117411&postcount=3339

[SaschaW]

NVIDIA Shader Intrinsics für OpenGL/Vulkan* (https://developer.nvidia.com/reading-between-threads-shader-intrinsics)

Unter Vulkan aktuell nur über VK_NV_glsl_shader, also noch nicht in SPIR-V. Dürfte aber bald kommen, genauso wie herstellerübergreifende Intrinsics :)

[Rancor]

Das heisst mehr Dampf für Nvida Karten unter Vulkan ?^^

[Troyan]

Nein, nicht wirklich. Es sind wohl eher Blogpost um zu zeigen, dass man auch Shader Intrinsics unterstützt. Kleiner Wink Richtung id.

[Screemer]

Wird wohl verstaubt sein? Und dann noch diese Ambient Temps draußen. Geh da mal ordentlich mit Druckluft ran.

MfG
Welche 290 genau? Check mal dein PT, offenbar ist das zu hoch. Oder der Kühler taugt nichts. Null Probleme hier mit den beiden Games und der HiS R9 390 bei angenehmen ~1600RPM Lüfter.

Danke für die Tips. Das liegt schlicht an der xfx dd black. Die Karte wurde erst vor ein paar Tagen komplett zerlegt. Die temps waren aber schon von Anfang an so. Hab die Pads sogar mal gewechselt und sogar noch zusätzliche Kühler über den vrms angebracht (www.overclock.net/t/1517379/decrease-290-xfx-dds-hot-vrm-temps). Gebracht hat es nicht so viel. Das Problem mit den sehr heißen vrms ist aber von Anfang an bekannt. Da ist beim Design der dd Black (https://hardforum.com/threads/no-surprise-here-xfx-290-dd-vrm-temps-over-100c-at-stock-volts.1807742/) was schief gelaufen. Die wurden wohl sogar mal per rma getauscht. da ich meine Karte allerdings gebraucht gekauft habe, habe ich davon abgesehen. Nun hab ich mal wieder den arschbrenner installiert und die Spannung reduziert. Das bringt locker 10°c. Bilder der Karte gibts hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=11109965#post11109965

Es fällt halt in meinem Fall durchaus auf, dass doom mit Vulkan Hawaii noch mal nen ticken besser ausnutzt. Mantke bei bf4 war ne zeit lang der größte Heizer, dann folge Division, was die Latte gleich mal ein gutes Stück höher geschraubt hat (~95°c->~110°c). Jetzt eben doom mit noch höheren Temperaturen.

[SaschaW]

Nein, nicht wirklich. Es sind wohl eher Blogpost um zu zeigen, dass man auch Shader Intrinsics unterstützt. Kleiner Wink Richtung id.

Der interessante Teil ist der hier :
In parallel, we are also working with the respective Khronos working groups in order to find the best way to bring cross-vendor shader intrinsics already standardized in OpenGL over to Vulkan and SPIR-V. We are furthermore working on Vulkan and SPIR-V extensions to expose our native intrinsics, but prioritized the cross-vendor functionality higher, especially since there is notable overlap in functionality.

Unter OpenGL kann man die Intrinsics auf NV ja dank der Extensions ja schon etwas länger nutzen, unter Vulkan mit SPIR-V aber nicht. Dort aktuell nur über die NV-spezifische GLSL-Extension, die man aber für eine Release nicht verwenden will. D.h. zumindest für den Vulkan-Renderer kann man die z.B. bei iD noch nicht nutzen (die AMD Extensions für Intrinsics unter Vulkan nutzt man schon). Deshalb ist der obige Abschnitt so interessant ;)

Der Cross-Vendor Ansatz ist aber auch (verdammt) richtig, hoffentlich passt das schon ins nächste Vulkan Release.

[captain_drink]

Der Cross-Vendor Ansatz ist aber auch (verdammt) richtig, hoffentlich passt das schon ins nächste Vulkan Release.

Ausnahmsweise kein Wasser auf die Mühlen derjenigen, die in NV den gnadenlosen Verfechter des Proprietären sehen.

[Achill]

In parallel, we are also working with the respective Khronos working groups in order to find the best way to bring cross-vendor shader intrinsics already standardized in OpenGL over to Vulkan and SPIR-V. We are furthermore working on Vulkan and SPIR-V extensions to expose our native intrinsics, but prioritized the cross-vendor functionality higher, especially since there is notable overlap in functionality.



Unter OpenGL kann man die Intrinsics auf NV ja dank der Extensions ja schon etwas länger nutzen, unter Vulkan mit SPIR-V aber nicht. Dort aktuell nur über die NV-spezifische GLSL-Extension, die man aber für eine Release nicht verwenden will. D.h. zumindest für den Vulkan-Renderer kann man die z.B. bei iD noch nicht nutzen (die AMD Extensions für Intrinsics unter Vulkan nutzt man schon). Deshalb ist der obige Abschnitt so interessant ;)

Der Cross-Vendor Ansatz ist aber auch (verdammt) richtig, hoffentlich passt das schon ins nächste Vulkan Release.

Die Aussage auf dem Dev-Blog von NV ist aber schon vielschichtig. Zu aller erst konnte ich keine Info finden, wie eine Extension in Core oder ARB aufgenommen wird (Voting-Prozess sowie pot. Veto). Des weiteren ist mir nicht klar, ob in den verschiedenen Boards immer die gleichen Firmen/Member sitzen. Ich gehe davon aus, dass sich ARM z.B. mehr für OpenGL ES und jetzt für Vulkan interessiert im vergleich zu OpenGL 4.5 ... dies gilt für einige andere Member sicherlich auch.

Wenn dem so ist - was man wohl annehmen kann - so hat eine Core oder ARB (oder EXT oder NV/AMD/*) OpenGL Extension im Context von Vulkan ein anderes Gewicht und muss neu bewertet werden, da es eine größere Menge an Interessieren => Votern gibt und es zu evtl. anderen Ergebnissen kommt.

Die Aussage im Blog zu Cross-Vendor hat erst Substanz (imho), wenn man den Voting-Prozess verstehen kann und damit was Cross-Vendor wirklich bedeutet. Leider habe ich auf die schnelle nix auf der Webseite gefunden. Daher bleibt meine Frage, was heißt Cross-Vendor für NV, offen.


Ausnahmsweise kein Wasser auf die Mühlen derjenigen, die in NV den gnadenlosen Verfechter des Proprietären sehen.

Das Eine hat mit den Anderen nichts zu tun.

[iuno]

Khronos hat die SIGGRAPH Videos jetzt endlich auch auf YT: https://www.youtube.com/user/khronosgroup/videos

Habe jetzt also auch endlich die Praesentation von Coda gesehen. Bzgl. AC sagt er an dieser Stelle (https://www.youtube.com/watch?v=CsHMiEQgrLA&t=4090), dass sie fuers rendertarget VK_SHARING_MODE_CONCURRENT verwenden, d.h. dass man von allen Queues aus Zugriff auf den Buffer hat (https://www.khronos.org/registry/vulkan/specs/1.0/man/html/VkSharingMode.html). Das sei bei einigen Karten mangels Kompression aber langsamer. Betrifft das nur AMD, Nvidia oder beide?
Ich vermute, man wuerde dann die Buffer mit den DMAs kopieren, die mind. bei AMD keine DCC unterstuetzen. Hat Nvidia da auch "Probleme"?

[y33H@]

Weil die Frage mal aufkam: Zumindest in Doom mit einer Radeon RX 470 steigt die Leistungsaufnahme der Karte beim Wechsel von OGL auf Vulkan fast nicht an, hier sind's gerade einmal +3 Watt (bei +25 Prozent mehr fps).

[kuj0n]

Und wieviel Watt sind das insgesamt so? *hust*

[iuno]

Halb-OT, aber an der Steckdose gemessen?
CPU wird ja entlastet, wirkt dem also entgegen oder?

[y33H@]

Die Karte selbst, Gesamtsystem geht um +12 Watt hoch, evtl weil die CPU schneller Daten anliefern muss.

[Raff]

Ist doch logisch, wenn das Limit der Karte fix ist.

MfG,
Raff

[blaidd]

Trotzdem gut 40 Prozent Fps-Plus in Doom... selbst mit einer ganz kleinen Karte ;)

[y33H@]

Bei ner Fury X oder Nano wäre interessant, wie viel die durch Vulkan mehr verheizt - morgen vll ...

[kuj0n]

Ihr lauft hier wieder zur Höschtform auf. Ganz großes Kino... :ubash2:

[StefanV]

Gibts schon Infos, ab wann Doom/Vukan auch mehrere Grafikkarten unterstützt?!

[Foobar2001]

Solange Vulkan es nicht unterstuetzt wohl kaum.

[StefanV]

Deswegen fragte ich, ob es Infos gibt, wann Doom und/oder Vulkan das unterstützt ;)

[Ganon]

Vermutlich in Vulkan 1.1 dann... Es wird momentan unter dem Namen Vulkan Next spezifiziert. Wann das fertig wird, kA. Ob DOOM das dann hinter nachliefert ist dann fraglich.

[iuno]

Was kommen denn noch fuer Spiele mit id-tech 6? Wird die Engine eigentlich lizenziert?

edit: https://www.youtube.com/watch?v=-UhHcEiegb8 :)

[Achill]

Gibts schon Infos, ab wann Doom/Vukan auch mehrere Grafikkarten unterstützt?!

siehe:

Nein, noch gibt es kein Support für mGPU in Vulkan v1.0 (https://lunarg.com/faqs/vulkan-multiple-gpus-acceleration/) - zumindest kein DMA/Transfer/Copy zwischen den Karten. Man soll wohl fertige Bilder über den Host-Memory transferieren können - das wäre aber langsam, da GPU1 -> (CPU <-> RAM) -> GPU2...

Im Talk gestern ist es für Vulkan Next (v1.1?) schon angekündigt:

[dildo4u]

Doom Vulkan mit FX 8350 + 480 vs 1060.

https://youtu.be/erAh6EAEu08?t=4m48s

Komische Ergebnisse die 480 ist nur mit den Intel vor der 1060,irgendwie scheint die CPU Entlastung bei AMD nicht ordentlich zu funktionieren.

[Gorkon]

RX 480 - 1080p OGL zu Vulkan: 87 / 91 | 1440p: 59 / 81 (Doom)

Komische Ergebnisse triffts ganz genau. Messungen ohne Dokumentation der Systeme o.Ä. Da kann ich auch alles random auswürfeln. Next please :rolleyes:

EDIT: Einzige Erkenntnis wenn die Messwerte halbwegs stimmen: Ab 1440p ist die CPU fast egal xD

[-/\-CruNcher-/\-]

Was soll man dazu sagen du vergleichst einen 8 core Intel mit einem 8 core AMD das kann niemandem sein ernst sein ;)

Der test ist einfach nur total unbalanciert mehr nicht ;)

So erreichst du nie eine Kosten Reduktion für den Enduser und letztendlich die Masse.

Das sind die Massentargets momentan

i5-2500
i5-3330
i5-3550
i7-3770

[dildo4u]

Ich kapier eure Posts nicht sollte Vulkan nicht genau Leute helfen die keine High-End CPU haben,ich find die Ergebnisse enttäuschend als FX8320 Besitzer.
Ein FX 8350 sollte locker 2 fache Konsolen Performance raushauen sobald der dicke API Layer beseitigt ist.

[-/\-CruNcher-/\-]

Es ist Lower Level aber nicht vollkommen Low Level ;)

AMDs Verbesserungen must du hier mit ihrer neuen PC Platform abwarten die sich in Richtung Konsolen neigt :)

[SaschaW]

Ich hab den Quake Vulkan Port von Axel (aka Coda) um Androidsupport erweitert:



Testen kann ich nur auf meinem Shield TV, aber da ist es komplett spielbar.

Momentan fehlen noch ein paar Dinge wie z.B. der Sound, und man kann noch keine Spielstände laden und speichern.

Wers mal ausprobieren will, [url=https://github.com/SaschaWillems/vkQuake]hier ist mein Fork mit Android -Support (]https://youtu.be/MASJiTN2P2k[/url). Benötigt wird das Android NDK und das Vulkan SDK, Buildskripte (Python) sind dabei, sollte also out-of-the-box compilieren.

Binaries gibt es keine, da die .pak Files mit in die .apk müssen, und da will ich nix verteilen was nicht mir gehört. Details dazu in der Android readme (https://github.com/SaschaWillems/vkQuake/blob/master/Android/README.md).

[Screemer]

Die Shareware pakfiles sollten da doch keine Probleme machen, oder?

[-/\-CruNcher-/\-]

Ich hab den Quake Vulkan Port von Axel (aka Coda) um Androidsupport erweitert:



Testen kann ich nur auf meinem Shield TV, aber da ist es komplett spielbar.

Momentan fehlen noch ein paar Dinge wie z.B. der Sound, und man kann noch keine Spielstände laden und speichern.

Wers mal ausprobieren will, [url=https://github.com/SaschaWillems/vkQuake]hier ist mein Fork mit Android -Support (]https://youtu.be/MASJiTN2P2k[/url). Benötigt wird das Android NDK und das Vulkan SDK, Buildskripte (Python) sind dabei, sollte also out-of-the-box compilieren.

Binaries gibt es keine, da die .pak Files mit in die .apk müssen, und da will ich nix verteilen was nicht mir gehört. Details dazu in der Android readme (https://github.com/SaschaWillems/vkQuake/blob/master/Android/README.md).


Irgendwie deutet das doch alles daraufhin das wir anstelle von Quake dort bald Doom 2016 auf dem Schirm sehen was ja ansich ultra geil wäre bei ~15W und noch Tegra X1 :D

Damit setzt sich Coda dann ein kleines Denkmal, ohne das aufwendige TAA sind dann wohl vieleicht sogar die magischen 60 fps drin ;)

Um seine und Tiagos ex Kollegen und die CryEngine ist es ja sehr ruihg geworden Crysis 3 on Shield on Hold vor allem da er ja wie wild am Linux port bastelte bevor er ging ;)

@Saschaw
Wie werden die Texturen gehandelt ?


Man ich muss irgendwie schauen das ich das auf meinem RK3066 zum laufen bekomme Mali 400 hat doch Vulkan support ?

[Nightspider]

Also wenn bei Vulkan Benchmarks immer noch AMD Grafikkarten von einer stärkeren Intel CPU profitieren muss der Treiber Layer (Overhead) noch zu dick sein.

Da kann man nur hoffen das sich am Treiber noch viel tut bzw. das Vega eben nicht mehr dieses Problem haben wird.

[Achill]

Doom Vulkan mit FX 8350 + 480 vs 1060.

https://youtu.be/erAh6EAEu08?t=4m48s

Komische Ergebnisse die 480 ist nur mit den Intel vor der 1060,irgendwie scheint die CPU Entlastung bei AMD nicht ordentlich zu funktionieren.

Wenn man sich das Video anschaut, fallen mir ein paar interessante Dinge auf:
1. Unter OpenGL! ist die 480 schneller als eine 1060 mit einen FX8350
2. Es gibt nur +2fps mehr unter OpenGL mit einen 6700k anstatt einen 8350 bei einer 480
3. Die 1060 braucht einen 6700k um mit OpenGL in der nähe Vulkan zu sein.
4. Die 1060 stagniert in Richtung 105 fps egel bei welcher API

Ein Abhängigkeit von der reinen IPC Leistung scheint es nicht alleinig zu sein. Wenn z.B. die 480 noch Luft bei einen 8350@Default hat, so müsste man schon mehr FPS bei 8350@4.4 Ghz sehen (NV äquivalent). Ich tippe darauf, dass sowohl bei Cache und Ram jeweils die Bandbreite sowie Timings für Doom wichtig sind - und dies anscheinend unterschiedlich stark bzgl. NV und AMD-Treiber und jeweiliger API.

In 1440p zeigt sich dann, dass die 1060 früher am Limit ist als die 480 (beim aktuellen Stand von Doom) und hier dann kein CPU-Limit bei beiden Karten mehr vorliegt (zumindest unter Vulkan).

[SaschaW]

@Saschaw
Wie werden die Texturen gehandelt ?
Wie meinst du das? Die werden ganz traditionell beim Start via Staging in den VRAM geschoben.

Man ich muss irgendwie schauen das ich das auf meinem RK3066 zum laufen bekomme Mali 400 hat doch Vulkan support ?

Nein. Hier steht welche ARM-Chips Vulkan können (http://malideveloper.arm.com/documentation/developer-guides/vulkan/).

Die meisten Android Vulkan Implementationen sind aber noch ziemlich Beta, Shield ausgenommen.

Rein technisch sollte der Port aber auf allen Android-Geräten mit Vulkansupport laufen, da keine besonderen Features verwendet werden. Es fehlen momentan halt Touchcontrols.

[-/\-CruNcher-/\-]

Wenn man sich das Video anschaut, fallen mir ein paar interessante Dinge auf:
1. Unter OpenGL! ist die 480 schneller als eine 1060 mit einen FX8350
2. Es gibt nur +2fps mehr unter OpenGL mit einen 6700k anstatt einen 8350 bei einer 480
3. Die 1060 braucht einen 6700k um mit OpenGL in der nähe Vulkan zu sein.
4. Die 1060 stagniert in Richtung 105 fps egel bei welcher API

Ein Abhängigkeit von der reinen IPC Leistung scheint es nicht alleinig zu sein. Wenn z.B. die 480 noch Luft bei einen 8350@Default hat, so müsste man schon mehr FPS bei 8350@4.4 Ghz sehen (NV äquivalent). Ich tippe darauf, dass sowohl bei Cache und Ram jeweils die Bandbreite sowie Timings für Doom wichtig sind - und dies anscheinend unterschiedlich stark bzgl. NV und AMD-Treiber und jeweiliger API.

In 1440p zeigt sich dann, dass die 1060 früher am Limit ist als die 480 (beim aktuellen Stand von Doom) und hier dann kein CPU-Limit bei beiden Karten mehr vorliegt (zumindest unter Vulkan).


Ja wir haben hier viel zu wenig informationen über beide Systemkonfigurationen im Gesammten, AMD schreibt die Daten wenigstens relativ ausführlich in ihre End Disclaimer.

Zudem ist Nvidia gerade wieder heftig dabei an ihren Timings und dem PWM rumzufeilen, da ändert sich fast täglich was für WDDM 2.0/2.1 momentan mit Pascal ;)


Wie meinst du das? Die werden ganz traditionell beim Start via Staging in den VRAM geschoben.



Nein. Hier steht welche ARM-Chips Vulkan können (http://malideveloper.arm.com/documentation/developer-guides/vulkan/).

Die meisten Android Vulkan Implementationen sind aber noch ziemlich Beta, Shield ausgenommen.

Rein technisch sollte der Port aber auf allen Android-Geräten mit Vulkansupport laufen, da keine besonderen Features verwendet werden. Es fehlen momentan halt Touchcontrols.

Naja der effizienzhalber wäre es ja vernünftig die Texturen in ASTC zu komprimieren was sicherlich bei dem Final Doom 2016 port passieren wird ;)

Schade erst ab T760

[Schnoesel]

Ich kapier eure Posts nicht sollte Vulkan nicht genau Leute helfen die keine High-End CPU haben,ich find die Ergebnisse enttäuschend als FX8320 Besitzer.

Keine Ahnung was dein Problem ist, ich habe einen brutalen Boost bei meinem Vishera in Doom mit Vulkan. Und das kann ich selbst nachvollziehen dank der Demoversion da brauch ich kein Youtube.

[dargo]

Doom Vulkan mit FX 8350 + 480 vs 1060.

https://youtu.be/erAh6EAEu08?t=4m48s

Komische Ergebnisse die 480 ist nur mit den Intel vor der 1060...
Viel lustiger finde ich, dass AMD unter OpenGL in 1080p mit dem Bulldozer schneller als NV ist. Mal was ganz neues... :ulol:

[Hübie]

Der Treiber bei NV braucht einfach deutlich mehr CPU-Zeit. Das sieht man auch im TXP-Thread wenn man HisN seine Vergleiche zwischen GP104 und GP102 ansieht.

[-/\-CruNcher-/\-]

Auch schon aufgefallen vor allem bei DX 12 wird es sehr evident und auch bei DX 11 durch die Command lists die zusätzlich overhead verursachen ;)

Sobald die CPU zu low cost wird geht es abwärts ;)

Jetzt kommen noch die PWM probleme DPC latenzen und Memory Probleme hinzu die wie wild versucht werden irgendwie zu umgehen tada WDDM 2.1 is born ;)

[SaschaW]

Naja der effizienzhalber wäre es ja vernünftig die Texturen in ASTC zu komprimieren was sicherlich bei dem Final Doom 2016 port passieren wird ;)

Schade erst ab T760

ASTC ist nur auf wenigen GPUs verfügbar (http://vulkan.gpuinfo.org/listreports.php?feature=textureCompressionASTC_LDR). Technisch könnte es Sinn machen die für mobile GPUs nach ASTC zu komprimieren, bei den wenigen und kleinen Texturen wird das aber kaum was ausmachen.

[Loeschzwerg]

The current Plan Of Record is that Intel® is not supporting Vulkan on Windows drivers. The drivers that were made available on Developer.com are intended for Vulkan developers.
https://communities.intel.com/thread/104380?start=30&tstart=0

Das letzte Wort ist zwar noch nicht gesprochen, für den Moment ist die Aussage aber sehr ernüchternd :(

[hmmm]

R.I.P. iGPU

[-/\-CruNcher-/\-]

Intel setzt sich strikte targets das bedeutet wohl für die Zukunft

Windows = OpenGL/DX 12 (only)
Android/Linux/Other = OpenGL/Vulkan

[DanMan]

Wer Performance benötigt benutzt wohl kaum iGPUs, und braucht dann auch kein Vulkan.

[Hübie]

Wenn einige hier wüssten wie man bei Intel arbeitet, dann... :freak:

[Achill]

Intel setzt sich strikte targets das bedeutet wohl für die Zukunft

Windows = OpenGL/DX 12 (only)
Android/Linux/Other = OpenGL/Vulkan

Ja, Vulkan ist für Intel unter Linux und Android (und wenn man mit seinen Chips weiter bei Android mitspielen will) wichtig.
- Linux: Vulkan sieht für das Wayland Protocol expliziten Support seit der ersten Version vor: https://www.collabora.com/about-us/blog/2016/02/16/vulkan-1.0-specification-released-with-day-one-support-for-wayland/
- Android: Mit Android N, DP2 wird Vulkan auf den ersten Geräten unterstützt. Ich gehe davon aus, das es für spätere Versionen verpflichten wird: https://developer.android.com/ndk/guides/graphics/getting-started.html

Wer Performance benötigt benutzt wohl kaum iGPUs, und braucht dann auch kein Vulkan.

Siehe Antwort an CruNcher... nicht alles dreht sich um PC-Gaming (Windows).

Wenn einige hier wüssten wie man bei Intel arbeitet, dann... :freak:

Unter Linux kann man das nicht gut Verstecken, gibt ja die Git-History... und wer auf seinen ThinkPad (gut gibt noch die Dinger mit dem angebissenen Apfel) kein Linux lauf hat, dem .. ääähhhmmm .. der hat es nicht anders Verdient. :devil:

---
Edit:
libretro & Vulkan support (http://www.libretro.com/index.php/day-1-vulkan-support/)
LibRetro in Action: https://www.youtube.com/watch?v=4NkMsASritM

---
E2: Typos

[Loeschzwerg]

Von Treiberentwicklung habe ich keinen Dunst, aber wenn eh an Vulkan Treibern für "Linux" geschraubt wird, dann sollte sich das doch eh recht einfach auf Windows umsetzen lassen und umgekehrt, oder nicht?

Der Linux Treiber ist ja auch nicht wirklich aktuell :(

Wer Performance benötigt benutzt wohl kaum iGPUs, und braucht dann auch kein Vulkan.

Schon klar, aber NV/AMD langweilen halt einfach nur hart :freak:

[-/\-CruNcher-/\-]

Ja, Vulkan ist für Intel unter Linux und Android (und wenn man mit seinen Chips weiter bei Android mitspielen will) wichtig.
- Linux: Vulkan sieht für das Wayland Protocol expliziten Support seit der ersten Version vor: https://www.collabora.com/about-us/blog/2016/02/16/vulkan-1.0-specification-released-with-day-one-support-for-wayland/
- Android: Mit Android N, DP2 wird Vulkan auf den ersten Geräten unterstützt. Ich gehe davon aus, das es für spätere Versionen verpflichten wird: https://developer.android.com/ndk/guides/graphics/getting-started.html



Siehe Antwort an CruNcher... nicht alles dreht sich um PC-Gaming (Windows).



Unter Linux kann man das nicht gut Verstecken, gibt ja die Git-History... und wer auf seinen ThinkPad (gut gibt noch die Dinger mit dem angebissenen Apfel) kein Linux lauf hat, dem .. ääähhhmmm .. der hat es nicht anders Verdient. :devil:

---
Edit:
libretro & Vulkan support (http://www.libretro.com/index.php/day-1-vulkan-support/)
LibRetro in Action: https://www.youtube.com/watch?v=4NkMsASritM

---
E2: Typos

Ja es wird wohl ein doppelfaktor sein kosten einsparen und Microsoft nicht gänzlich gegen das schienbein tretten ;)

Für Intel ein Win/Win, alllerdings wird der demand der user (Entwickler,Publisher) zu hoch knicken sie sicherlich ein, abwarten wie der demand wird.

Es kann aber auch genau das gegenteil bedeuten das Intel sich mehr von Microsoft entfernen will und zu Google tendiert ;)

Intel spielt eine wichtige Rolle innerhalb Microsofts Mobile UWP Plänen, allerdings ist Intel wohl auch nicht Happy über die Stellung die AMD dort eingenomen hat und langsam ausbaut, wär ich auch nicht wenn ich meinem langjährigen Partner so häufig beim Bettgeflüster zu schauen müsste ;)

Du kannst ja davon ausgehen das wenn Microsoft mal ihre Xbox Mobile die sie schon länger in der Schublade mit sich herumtragen rausholt die sicherlich nicht Intel Powered sein wird momentan.

[iuno]

Bei Intel arbeitet afaik das Linux Treiberteam unabhaengig von dem fuer Windows.
Nvidia teilt den Grossteil des Codes und bei AMD ist es irgendwo dazwischen.
afair wollte Intel das Engagement aber schon laenger zurueckfahren, ein schlechter Weg den sie dort einschlagen...