Vulkan Grafik-API

[vinacis_vivids]

Bei PCGH ist es wieder umgekehrt. Was soll das nun sagen bzw. worauf willst du hinaus? :|

Muss dich leider enttäuschen:

https://abload.de/img/snel44k55s70.png

Fury X zeigt 10% schnellere min fps. als 1070. Ich wette, dass kein Wundertreiber von Nvidia diese Lücke aufholen kann.

[Hübie]

Ich wette, dass kein Wundertreiber von Nvidia diese Lücke aufholen kann.

Wahrscheinlich nicht. Aber schau mal auf das Bild von dildo4u. Da ist die 980 Ti wieder schneller (die ja im Grunde genau so schnell ist wie die 1070). Keine Ahnung warum. Aber ich weiß immer noch nicht worauf du hier im Vulkan-Thread hinaus möchtest.
In Doom @Vulkan hat man es geschafft, Fiji besser auszulasten, weil die Entwickler sich auch wirklich die jeweilige Performance angesehen, analysiert und optimiert haben. Das scheint aufwändig zu sein und lohnt sich für die meisten Studios nicht. Insgesamt fährt man mit Fiji wohl einfach nicht so gut wie mit GM200. Da ich keine Fiji habe, kann ich nur mutmaßen, aber wenn ich immer so Vergleiche anstelle, bereue ich nichts. :D
Und Hand aufs Herz: Willst du dieses Spiel mit einen dieser Karten @max 4k zocken? Eher nicht. ;)
Vega wird hier ja oft als Fiji done right gehandelt und wenn man sich nun vorstellt die 4096 ALUs werden wie bei Pascal gut ausgelastet... Da könnte es corner cases geben wo man eben auch an der 1080 Ti knapp dran vorbei zieht. Gab es ab und zu auch mit Fiji <-> GM200 nur das damals die Anzahl der ALUs sehr stark voneinander abwich (1024 damals vs. 256 im künftigen Duell).

[vinacis_vivids]

Mir ging es um die Differenz zwischen Fiji vs. Pascal. Die differiert zwischen den Spielen.
Im diesem Fall von DX12@AC liegt 30% zwischen TitanX und FuryX in min fps.
Sollte Vega in Vulkan@4k perfekt harmonieren, ist das auch ein Türöffner für diese API. Entwickler werden diese Optionen schätzen und die 4k Tür weiter öffnen für Leute die sich keine 800-1300€ Karte leisten können. Quasi resolution-upgrade für die Masse, weil Nvidia kein Angebot hat.

[captain_drink]

Ist hier wieder Zeit für den AMD-circlejerk? Mit dem Thema haben die letzten beiden Seiten jedenfalls nichts zu tun...

[gravitationsfeld]

,ich vermute mal wenn Fury in 4k mithält werden Detail's ausgeblendet weil sie nur 4GB Ram hat.
Vermutest du falsch :)

[Hübie]

Mir ging es um die Differenz zwischen Fiji vs. Pascal. Die differiert zwischen den Spielen.
Im diesem Fall von DX12@AC liegt 30% zwischen TitanX und FuryX in min fps.
Sollte Vega in Vulkan@4k perfekt harmonieren, ist das auch ein Türöffner für diese API. Entwickler werden diese Optionen schätzen und die 4k Tür weiter öffnen für Leute die sich keine 800-1300€ Karte leisten können. Quasi resolution-upgrade für die Masse, weil Nvidia kein Angebot hat.

Die Spieleindustrie tickt da n bissl anders. Ich begrüße zwar Vulkan, aber du wirst dich wundern wie viele Devs noch keine Berührung mit Vulkan hatten.
Die min-fps sind übrigens meistens nicht verwertbar. Wenn in 1000 ms ein frame mal 50 ms braucht hast du einen hässlichen min-fps Wert aber das würdest Du gar nicht bemerken. ;) Du verstehst hoffentlich worauf ich hinaus möchte.

[dildo4u]

Vulkan für Ashes of the Singularity: Escalation voraussichtlich kommt im Juni.

http://steamcommunity.com/app/507490/discussions/0/133262848300580905/

[Kartenlehrling]

zwei neue Baustellen bei Bethesda,
ich hoffe doch sehr das die gleich Vulkan als Haupt-API haben.



https://pbs.twimg.com/media/C-hgReFW0AE1NYL.jpg


Invites have gone out for the Bethesda E3 Showcase.
Stay tuned for your chance to win tickets to join us at Bethesdaland on Sunday, June 11.
https://twitter.com/DCDeacon/status/858041853333172224

[Hübie]

Also noch benutzen die zu viele unterschiedliche Engines um auf id tech 6 zu spekulieren. Prey kommt mit CryEngine, Dishonored 2 nutzt Void (welche Basis is das), Doom id tech6, Fallout Creation...
Das ist noch der reinste Gemüsegarten.

[aufkrawall]

Interessanterweise läuft Talos Principle auf Linux mit Vulkan etwas schneller im CPU-Limit als unter Windows:

Windows:
Vulkan: 358fps
DX11: 350fps

Linux:
Vulkan: 386fps

(lowest GPU Details, Rest Ultra, Nvidia 381.22 & 382.19, Windows 10 RS2, Linux 4.11.1, Benchrun 30s)

Ist vollständig CPU-limitiert und ich hatte unter Windows auch testweise alles abgeschaltet, was abgeschaltet werden kann.
Hat man unter Windows noch mehr Abstraktion und somit mehr Overhead?

[gravitationsfeld]

Kann an allem moeglichen liegen.

[d2kx]

Aus der OpenCL 2.2-Ankündigung:

We are also working to converge with, and leverage, the Khronos Vulkan API — merging advance graphics and compute into a single API.


Khronos Releases OpenCL 2.2 With SPIR-V 1.2 (https://www.khronos.org/news/press/khronos-releases-opencl-2.2-with-spir-v-1.2)
Khronos Group

[Ganon]

Und das macht NVidia mit? Gut, man kann es natürlich auch "optional" machen und NVidia unterstützt dann einfach den OpenCL Teil von Vulkan nicht (vollständig).

[gravitationsfeld]

Sie werden wohl keine Wahl haben, wenn sie Vulkan unterstuetzen wollen.

[Vulkanier]

Ballistic Overkill hat nun auch Vulkan support.
Nur schade as mit RADV mal wieder gar nichts läuft,
http://www.phoronix.com/scan.php?page=article&item=ballistic-overkill-vulkan&num=1

Shroud of the Avatar folgt ende des Monats (R43) wenn alles gut geht.

[dildo4u]

Wer noch ne Stelle zum Benchen sucht es gibt bei Doom später extrem CPU Lastige Stellen.Im Level Argent Energy Tower.

FX8320e@4.2GHz GTX 1070 2GHZ 1080p Ultra

Open GL 4.5 56fps

http://abload.de/img/desktop06.03.2017-10.b4o9t.png

Vulkan 95 fps

http://abload.de/img/doom06.03.2017-10.18.x8jpj.png

[pixeljetstream]

Und das macht NVidia mit? Gut, man kann es natürlich auch "optional" machen und NVidia unterstützt dann einfach den OpenCL Teil von Vulkan nicht (vollständig).

Meiner Meinung nach wird das kein Problem sein, der Mangel an OpenCL 2 Unterstützung liegt eher daran dass OpenCL 2 praktisch keine treibende Platform mehr hinter sich hat. Apple welche OpenCL begründeten ist lange raus und blieb bei CL 1.2 stehen und hat nun sein Metal, NVIDIA hat noch extensions unterstützt für 1.2, aber halt nicht mehr in 2.x investiert weil der Bedarf im Markt nicht da ist.

CL ist nicht mehr "die" Lösung für Workstation (kein Apple mehr), Android hatte seine eigene compute Lösung, Linux ist durch GL (compute leider viel zu spät) und andere interfaces für HPC abgedeckt (CUDA, bzw. Intel's ispc, tbb etc.).

Bei Vulkan ist die Situation besser weil hier Android als große Platform wichtig ist. Es ist also viel aussichtsreicher in Vulkan zu investieren und NVIDIA ist hier sehr aktiv in Khronos.

[Ganon]

Meiner Meinung nach wird das kein Problem sein, der Mangel an OpenCL 2 Unterstützung liegt eher daran dass OpenCL 2 praktisch keine treibende Platform mehr hinter sich hat.

Also ich kenne einige Projekte die sofort OpenCL 2.x genommen hätten, wenn es denn verfügbar gewesen wäre. Aber so ist es nunmal, wenn der Marktführer eine API nicht implementiert.

Es ist schon ein bisschen naiv anzunehmen, dass bei der massiven Verbreitung von CUDA, NVidia OpenCL nicht erweitert "weil kein Bedarf da ist". NVidia will schlicht, wie bei der nicht-Unterstützung von Free/AdaptiveSync, ihren eigenen Kram durchdrücken.

Apple spielt bei High Performance Kram eh schon keine Rolle mehr. Bieten ja nicht mal die Hardware für sowas an.

[Screemer]

Du kannst dir sicher sein, dass er genau weis warum sein Arbeitgeber keine cl-updates bringt.

[Hübie]

Als ich 2015 noch mit so etwas zu tun hatte gab es ein paar Spielkälber mit AMD / OCL und die bekamen mit der Zeit mehr Frust als Lust, je weiter die voran schritten. Ende vom Lied war dass es aus dem Projekt gekickt worden war und man mit NV / CUDA alles umgesetzt hatte. Die Produktivität stieg dadurch schon enorm an, da auch kein umfangreiches Wissen erforderlich ist, die Doku bzw. der Support deutlich besser war und nicht zuletzt der Erfahrungsaustausch durch höhere Verbreitung umfangreicher ausfiel.
Es ist nicht immer von Vorteil alles offen und frei zu machen und es dreht sich auch nicht immer nur um die Anschaffungskosten. Das mag nicht jeder verstehen, der nicht damit zu tun hat, aber man kann eben nur nehmen, was auf dem Markt ist.
Vulkan kann hier ein wesentlich festeres Standbein aufbauen, wenn man auch schnell auf neue ISA reagiert (CUDA ist da ja quasi instant - logisch :D).

[iuno]

Es ist nicht immer von Vorteil alles offen und frei zu machen und es dreht sich auch nicht immer nur um die Anschaffungskosten.
Als Nutzer gibt es keinen einzigen Nachteil, sondern nur Vorteile. Im Uebrigen ist das voellig unabhaengig davon, welche Loesung individuell besser ist (oder besser sein soll)

[StefanV]

Es ist nicht immer von Vorteil alles offen und frei zu machen.
Ja, für den Hersteller, nicht aber für den Nutzer.
Warum möchtest du nicht aus Nutzersicht argumentieren?!


Denn für den ist eine standardisierte Schnittstelle, die von jemdem Hersteller genutzt werden kann, sehr wohl von Vorteil. Proprietäres Zeugs bringts nur für denen, der das verbrochen hat.
Siehe Glide damals und dem anderen ganzen Zeugs. War das wirklich ein Vorteil für den User?! I don't think so...

[Ganon]

Du kannst dir sicher sein, dass er genau weis warum sein Arbeitgeber keine cl-updates bringt.

Ändert nichts dran dass die Aussage "kein Bedarf am Markt" seltsam ist, wenn alle CUDA nehmen, weil es Features hat, die OpenCL 1.2 nicht hat, aber OpenCL 2.x sie hätte... genauso kann Apple jetzt auch behaupten, für OpenGL sei kein Bedarf, da alle Metal wollen.

Ich mein, ich seh's doch, dass ein Haufen Projekte auf OpenCL 1.2 festhängen, weil NVidia nicht mitmacht... das denke ich mir doch nicht aus :ugly:

[Hübie]

Als Nutzer gibt es keinen einzigen Nachteil, sondern nur Vorteile. Im Uebrigen ist das voellig unabhaengig davon, welche Loesung individuell besser ist (oder besser sein soll)

Definiere Nutzer. Der Spieler von Doom oder derjenige, der damit sein Programm zum laufen bringen muss? Für letzteren gibt es sehr wohl die von mir genannten Nachteile (späte Verfügbarkeit von Funktionen, lückenhafte Doku etc.). Ich betrachte es aus der Situation heraus, denn hypothetisch könnten wir technologisch viel weiter sein. Diese Erkenntnis bringt nur nix, da dem nicht so ist.

[aufkrawall]

Vulkan bekommt doch ständig neue Extensions spendiert?

[Hübie]

Und genau das macht ja Hoffnung.

[iuno]

Definiere Nutzer. Der Spieler von Doom oder derjenige, der damit sein Programm zum laufen bringen muss?
Beide sind Nutzer, ich schrieb ja extra "Nutzer" und nicht "Anwender".

Für letzteren gibt es sehr wohl die von mir genannten Nachteile (späte Verfügbarkeit von Funktionen, lückenhafte Doku etc.)
Voelliger Unsinn, hat rein gar nichts damit zu tun ob es ein offener Standard ist oder nicht, sondern damit, wie es angegangen wird.

Diese Erkenntnis bringt nur nix
Kommt darauf an, ob man gewillt ist aus der Vergangenheit zu lernen oder eben nicht.

[pixeljetstream]

Ändert nichts dran dass die Aussage "kein Bedarf am Markt" seltsam ist, wenn alle CUDA nehmen, weil es Features hat, die OpenCL 1.2 nicht hat, aber OpenCL 2.x sie hätte... genauso kann Apple jetzt auch behaupten, für OpenGL sei kein Bedarf, da alle Metal wollen.

Ich mein, ich seh's doch, dass ein Haufen Projekte auf OpenCL 1.2 festhängen, weil NVidia nicht mitmacht... das denke ich mir doch nicht aus :ugly:

Das ist meine Ansicht, nicht die meines Arbeitgebers. Für mich bediente OpenCL Bedarf bei "workstation compute/grafik" (weil es historisch ja vor compute shadern in GL kam und Apple jene ja nie unterstützte), Projekte die noch mehr "rechnen" ala HPC greifen zu anderen Mitteln (OpenACC, OpenMP, Intel/CUDA etc.). In jenem HPC Markt war CUDA mit seinen Lösungen erfolgreich und Intel mit seinen diversen Libraries.

OpenCL spielte hier denke ich ne untergeordnete Rolle, vielleicht wäre die Rolle größer gewesen wenn NVIDIA auf CL 2.x aufgesprungen wäre, aber man kann durchaus mal nicht der erste sein und sehen ob es sich überhaupt lohnt da zu investieren, und es tat sich eben nicht viel und war durch Metal dann noch uninteressanter geworden. Hätte der Markt mehr Druck ausgeübt eine Lösung jenseits von CUDA, GL, Dx haben zu wollen, wäre es auch wirtschaftlich zu reagieren.

Die Alternative wäre gewesen CUDA früh zu begraben und alles in CL zu stecken. Das machte denke ich aber damals keinen Sinn, da noch sehr viel Bewegung in den features/hardware war, und man als Hersteller es dann unendlich leichter hat seinen eigenen Kram zu machen (Khronos braucht immer länger).

Mit proprietären Techniken kommt man ja nur durch wenn der Bereich wo es eingesetzt wird mit dem geleisteten zufrieden ist. Nichts hätte Intel oder AMD abhalten können die ganze Infrastruktur rund um CL viel stärker zu pushen und NVIDIA so unter Druck zu setzen, aber dies geschah nicht, sondern NVIDIA war mit seinem Investment rund um CUDA halt erfolgreicher.

Daher meine Aussage das es schon länger keinen großen Bereich gibt der nach CL schreit/investiert.

Bis Android, und jetzt hängt man halt alles an Vulkan auf.

Für die Entwickler heißt das ein Software-stack rund um Vulkan, und dann irgendwie Metal noch mit abdecken, dann erschlägt man viele Platformen und hat nicht diese multi-api Geschichten am hals wenn man am Ende die Daten eh irgendwie visuell darstellt. Im worst-case halt dx, vulkan, metal. Aber das ist immer noch besser als noch cl partiell in diesem mix zu haben.

[aufkrawall]

Kann man davon ausgehen, dass nach OCL 2.2 dafür nichts mehr kommt und komplett auf Vulkan-Extensions umgeschwenkt wird?

[pixeljetstream]

Ja, für den Hersteller, nicht aber für den Nutzer.
Warum möchtest du nicht aus Nutzersicht argumentieren?!


Denn für den ist eine standardisierte Schnittstelle, die von jemdem Hersteller genutzt werden kann, sehr wohl von Vorteil. Proprietäres Zeugs bringts nur für denen, der das verbrochen hat.
Siehe Glide damals und dem anderen ganzen Zeugs. War das wirklich ein Vorteil für den User?! I don't think so...

Aber war nicht Voodoo anfangs erfolgreich, trotz glide, und waren die Leute die eine hatten (die Kunden der Firma) nicht happy darüber was ihre Karten alles können?

Das soll nicht heißen Standards sind nicht wichtig, aber proprietäre Lösungen erlauben immer schnellere Innovation für den Hardwarehersteller, und solche die diese Features schnell nutzen können. Die Standards ziehen immer hinterher. GL/VK zieht mit den Standardversionen immer hinter Microsoft, weil mehr Parteien sich einigen müssen (und das obwohl viele der Parteien sich ja auch mit MS einigen müssen). Das heißt wenn Du Technik schnell willst, ist das manchmal nicht der beste weg.

[Hübie]

Beide sind Nutzer, ich schrieb ja extra "Nutzer" und nicht "Anwender".

Und ich schrieb für wen es relevant ist.

Voelliger Unsinn, hat rein gar nichts damit zu tun ob es ein offener Standard ist oder nicht, sondern damit, wie es angegangen wird.

Es gibt doch einen Zusammenhang aus lückenhafter oder mangelhafter Doku und open source. Dachte du programmierst selber? Meiner Erfahrung nach: Je klüger der Kopf, desto schlampiger der Mensch. Das spiegelt sich auch dort wieder. Ich erinnere mich an fluchende Wissenschaftler weil es einige Funktionen in OCL nicht, nicht richtig oder nur fehlerhaft gab. Da es aber AMD Fanboys waren, war es verdammt hart denen CUDA aufzudrücken. Nun ja. Danach war Ruhe. :redface:

Kommt darauf an, ob man gewillt ist aus der Vergangenheit zu lernen oder eben nicht.

Das ist ne Frage des Zeitraums. Lernen tun se alle irgendwie. Nur wann du ein Ergebnis siehst kann man schwer abschätzen.

War GLIDE nicht im Grunde auch eine LL-API oder war es eher eine Sammlung "spezializierter Extension" für OGL (ähnlich der NV-only extensions)? Ich erinnere mich da leider nicht mehr sehr gut dran. :confused:

[pixeljetstream]

Kann man davon ausgehen, dass nach OCL 2.2 dafür nichts mehr kommt und komplett auf Vulkan-Extensions umgeschwenkt wird?

Du meinst keine neue OCL runtime mehr? So würde ich zumindest das Khronos statement interpretieren. Der Focus ist auf SYCL und die C++ Erweiterungen, also primär die "Compute Sprache".

[iuno]

Offene Standards haben nicht unmittelbar mit freier Software zu tun. Ja, ich programmiere und es besteht ueberhaupt kein Zusammenhang. Ich glaube du kannst dir ausserdem gar nicht vorstellen oder schaetzt es voellig falsch ein was es fuer einen Haufen schrottiger und nicht oder schlecht dokumentierter closed Softwaregibt. Und wenn es keine Doku gibt, kann ich in einem Fall wenigstens im Code nachschauen, auch wenn es bei steigender Komplexitaet natuerlich nicht effizient bis hin zu nicht mehr effektiv ist. Wie schon gesagt: es hat halt damit zu tun wie man es angeht und nicht ob es offen oder geschlossen ist.

Zu behaupten, das Eine oder Andere sei prinzipiell qualitativ besserer Code, besser dokumentiert oder sicherer (was auch oft vorkommt) ist jedes Mal Unsinn. Man koennte natuerlich abgesehen von der reinen Behauptung noch statistische Erhebungen machen, was aber auch nichts bringt.

[gravitationsfeld]

War GLIDE nicht im Grunde auch eine LL-API oder war es eher eine Sammlung "spezializierter Extension" für OGL (ähnlich der NV-only extensions)? Ich erinnere mich da leider nicht mehr sehr gut dran. :confused:
OpenGL war zu 1.x Zeiten auf damaliger Hardware viel mehr "low level" als heute, weil es keine Shader gab.

Glide sah aehnlich aus, war aber schon spezieller auf 3Dfx zugeschnitten und definitiv nicht nur eine OpenGL-Erweiterung.

[Loeschzwerg]

Bei Glide hat man sich, natürlich im Hinblick auf die eigene Hardware, schlichtweg das nötigste aus der existierenden OGL Welt genommen und für Einfachheit/Sauberkeit gesorgt.
Deswegen gab es ja auch schnell Glide Wrapper für OGL.

[Ganon]

Das soll nicht heißen Standards sind nicht wichtig, aber proprietäre Lösungen erlauben immer schnellere Innovation für den Hardwarehersteller, und solche die diese Features schnell nutzen können.

Für sowas gibt es aber schon immer Extensions ;)

Aber unabhängig davon. Die Argumentation rund um proprietäre APIs ist nichts neues. Wir reden ja hier nun auch nicht davon, dass NVidia hier irgendwas später, oder langsamer implementiert. Sie machen es schlicht _gar nicht_ (OpenCL 2.0 ist bald 4 Jahre alt, OpenCL 2.1 bald 2 Jahre). Genauso wie Free/Adaptive Sync nicht implementiert wird, weil sie ihr G-Sync verkaufen wollen.

Sorry, aber da braucht man nicht über für und wider diskutieren... NVidia ist aktueller Marktführer, fährt Milliardenumsätze ein und kriegt es nicht gebacken ne API zu implementieren. Aber für ihre eigene, geschlossene API hauen sie natürliche eine Version nach der Anderen raus. Selbst ein kleines Intel-Team in China schafft es für Intel GPUs unter Linux OpenCL 2.x zu implementieren. Und da kann man mir nicht erzählen, dass es daran liegt, dass OpenCL 2.x auf Intel GPUs sinnvoll wäre. Man bietet es einfach und gut. :ugly:

Du magst das ganze ja so sehen wie "will ja keiner haben, darum implementiert NVidia das auch nicht". Ich sehe hier nur, dass NVidia den Markt schlicht ausgehungert hat, bis alle zwangsweise auf CUDA gewechselt sind, weil AMD halb am Boden lag und Intel keine schnellen GPUs hat.
Die ganze Diskussion gäbe es für mich nicht (wie bei D3D, OGL, Vulkan), wenn NVidia einfach mal OpenCL vernünftig und in einer aktuellen Version unterstützen würde. Dann wäre wieder der Entwickler gefragt, nicht der Hersteller. Wir reden hier auch von 2... ja 2 (!) APIs... nicht 5 oder 6.

Das ist in meinen Augen schlicht Marktmacht-Missbrauch. Wenn Microsoft jetzt sagen würde "wir erlauben nur noch Direct3D unter Windows"... was meinst du was das für ein Theater wäre.

Ich kann mir natürlich nur wünschen, dass es mit Vulkan anders läuft, aber verzeihe mir, dass ich bisher nicht daran glaube. Bis Vulkan und OpenCL in einer sinnvollen Form vereinigt sind, vergehen vermutlich noch diverse Jahre, wenn es überhaupt passiert. Ich vermute eher, dass es eher auf eine Zwischenlösung hinaus läuft, die CUDA so nie ersetzen können wird.

Bis dahin sind hoffentlich die freien OpenCL -> CUDA Wrapper weit genug.

[Troyan]

Offene Standards bedeuten nicht, dass jeder Marktteilnehmer 100% in diese investiert. Sie dienen einzig dazu, dass der Markteintritt vereinfacht wird. Am Ende stehen auch offene Standards im klaren Konkurrenzkampf mit propritären und/oder geschlossenen Vorgehensweisen.

[Hübie]

Offene Standards haben nicht unmittelbar mit freier Software zu tun. Ja, ich programmiere und es besteht ueberhaupt kein Zusammenhang. Ich glaube du kannst dir ausserdem gar nicht vorstellen oder schaetzt es voellig falsch ein was es fuer einen Haufen schrottiger und nicht oder schlecht dokumentierter closed Softwaregibt. Und wenn es keine Doku gibt, kann ich in einem Fall wenigstens im Code nachschauen, auch wenn es bei steigender Komplexitaet natuerlich nicht effizient bis hin zu nicht mehr effektiv ist. Wie schon gesagt: es hat halt damit zu tun wie man es angeht und nicht ob es offen oder geschlossen ist.

Zu behaupten, das Eine oder Andere sei prinzipiell qualitativ besserer Code, besser dokumentiert oder sicherer (was auch oft vorkommt) ist jedes Mal Unsinn. Man koennte natuerlich abgesehen von der reinen Behauptung noch statistische Erhebungen machen, was aber auch nichts bringt.

OK zugegeben will ich das in dem Kontext des Threads belassen, das habe ich in der Tat nicht so deutlich ausgedrückt. Mea culpa. Wenn es um Programmbibliotheken, Programme und Anwendungen abseits CUDA vs OpenCL geht stimmt meine Aussage schon nicht mehr.

[Achill]

Standards dienen der Austauschbarkeit der unterschiedlichen Umsetzungen und befähigen den Nutzer / Konsumenten, eine Wahlmöglichkeit zu haben. Was wäre wenn unsere alltäglichen Dinge und Dienstleistungen keine Standards hätten und damit einher gehend das Angebots- und Preis-Chaos. Das wäre toll oder?

Daraus ergibt sich auch warum NV bei CUDA und OpenCL agiert wie sie es tun. Das Unterscheidet sich nicht von Firmen wie MS (Windows, Office), Oracle (DB), Apple (Devices, OS, Store) usw. usw. ...

Die Erzeugung eines künstlich gesicherten Ökosystems (im Sinne von nicht Austauschbarkeit) garantiert Kundenbindung und Einnahmen/Gewinn - um nicht mehr oder weniger geht es bei einen wirtschaftlich agierenden Unternehmen.

Innovation ist nie primärer Treiber sondern immer Mittel zum Zweck um eine Markt-Präferierte / -Beherrschende Stellung zu erreichen bzw. zu halten. I.d.R. gibt es in der Anfangsphase einen hohe Grad an Investition um überhaupt den Hebel für ein eigenes Ökosystem in der Hand zu haben. Ist das System erst einmal erfolgreich etabliert am Mark, werden i.d.R. die Investitionen zurück gefahren (soweit möglich / sinnvoll) und der Markt abgeschöpft.

Erst wenn es Konkurrenz gibt - die das Ökosystem/Gewinne bedrohen - ändert sich die Strategie wieder.

[pixeljetstream]

Das klingt so als wäre das alles ein Selbstläufer für Firmen und ich als Mensch würde mir jederzeit nur überlegen etwas nur zu verbessern um irgendwo ein Monopol für viel Geld zu schaffen. So rein kapitalistisch schätze ich uns Menschen dann doch nicht ein, es gibt eine Begeisterung in uns die Dinge voran zu bringen, und auch wenn damit Geld verdient wird, ist das nicht die Allmacht die uns treibt (auch wenn das jetzt philosophisch klingt). Leute wie unser oder andere CEOs die die Firma von klein aufbauten, haben selbst wahrlich genug Geld für sich und ihre Lieben um sich das nicht antun zu müssen. Ich würde behaupten als Ingenieur oder auch sonst wenn man einen kreativen Beruf hat, ist die Begeisterung dafür etwas aufzubauen, das was uns antreibt. Eine Firma ist kein Wesen, es sind viele Menschen, die würde ich behaupten nicht von Geld allein motiviert handeln.

Ich würde auch behaupten die Investitionen in CUDA lohnen sich erst jetzt dank Deep Learning richtig, davor war das Wachstum und Umsatz von Tesla sehr gering im Verhältnis zu den Kosten. CUDA wurde ja nicht einmal eintwickelt, sondern fortlaufend weiter und muss im HPC Markt ja immer aufs Neue sich gegen die Allmacht Intel's erwähren, oder jetzt halt neue Chips rund um Deep Learning. Das heißt man musste hier schon nen langen Atem haben und es war nicht leicht das über die Anfangsjahre zu rechtfertigen.

Das ist also schon ein großes Wagnis für Firmen, die natürlich damit Geld verdienen wollen/müssen um voran zu kommen. NVIDIA wuchs über die Jahre ordentlich an der Anzahl der Mitarbeiter (als ich eingestellt wurde 6000, jetzt rund 10 000) und engagierte sich in immer neuen Bereichen, bei tablet & phone ging das daneben. Ich denke also nicht dass man sich hier irgendwo zurücklehnt und nur abschöpft, dafür gibt es zu viele größere Technikfirmen, es gibt immer Konkurrenz.

Die Firma engagierte sich auch stark in OpenGL und Vulkan und ist in vielen Khronos Standards vertreten, nach deiner Logik hätte NVIDIA seine eigene Grafikapi machen müssen, das hat aber interessanterweise die andere Firma gewagt...
Wird aber wieder off-topic nun. Der Erfolg der Firma ist ja auch hart erarbeitet und es stehen viele Menschen dahinter, die Wagnisse und Investitionen hätten auch andere Firmen eingehen können.

[Naitsabes]

Ich behaupte jetzt mal ganz dreist, dass dir da so gesehen auch keiner widersprechen würde.
Aber es wäre ja trotzdem schöner gewesen, wenn das, was in CUDA gesteckt wurde, in OpenCL gesteckt worden wäre.
Natürlich hätte nVidia (und auch jeder andere Hersteller) versucht die API möglichst gut an die eigene Hardware anzupassen, und das ist auch deren gutes Recht.

Man hätte dann aber eine API, die (bis auf einige Extensions) herstellerunabhängig wäre. Auf einmal hätte man eine viel größere Zielgruppe. Auf einmal könnte ein hoch parallelisiertes Programm von jeder (aktuelleren) GPU beschleunigt werden.
Matlab mit OpenCL statt Cuda wäre für viele (wohl vor allem Studenten^^) ein Traum.
Die Teslas, FirePros und wie sie nicht alle heißen hätten durch den besseren (angepassteren) Treibersupport weiterhin vorteile (und auf Consumerhardware kann man ja immernoch die Leistung etwas einschränken.

[pixeljetstream]

Das leuchtet mir auch ein, und von GL kommend war ich selbst nie der große CUDA fan (ewig keine runtime generated shader), aber es addressierte halt primär einen anderen Markt, Angriff auf Intel, C++ Entwickler gewinnen. Immerhin war die consumerhardware nicht eingeschränkt, so dass es auch als Student/für die Uni kein Vermögen kostete. Sonst wäre CUDA nicht angenommen worden.

Compute shader in GL 3 wären mir lieber gewesen, so wie dx10 das rudimentär schon hatte. Meine eigene studentische 3d engine setzte auf Cg, was von NVIDIA eingestellt wurde ;) kenne also auch die Schattenseiten von proprietären Schnittstellen.

Damals war ja viel noch im Umbruch, AMD hatte auch noch sein CTM, Intel versuchte auch diverses, Intel Ct. Dann indirekt der "Konkurrenz" zu helfen wenn man stark in CL libraries investiert und die anderen nicht und dann später aufspringen ins gemachte Nest, ist halt aus Firmensicht nicht optimal. Auch vor dem Hintergrund das der große GL 3 Umbau (Longs Peak) auch damals voll in die Hose ging. Die Art und weise wie CUDA entwickelt wurde war auch nicht optimal für CL, CUDA war stark an andere C++ compiler gebunden (erst 2013 kaufte man The Portland Group und auch der LLVM Schwenk kam erst spät), CL aber benötigte runtime compilation wie GL.
Sprich so einfach "erfolgreich" sah ein Setzen auf CL halt auch nicht aus. Im nachhinein hätte NVIDIA hier auch alles intelligenter lösen können was Infrastruktur angeht, aber man ging halt an die Sache so ran um es schnell killen zu können falls es kein Erfolg ist. Es waren halt NVIDIAs Kosten/Risiken die Technik in die Welt zu tragen (SDKs, Matlab Integration usw.). Dann halt lieber volle Kontrolle über das eigene Schicksal.

Was "bessere Treiber" und so angeht, so denke ich das NVIDIA halt nicht den weg geht "nur hardware" zu sein, sondern eben Lösungsmittel, was Hilfe jenseits des Treibers angeht. So steigert man den eigenen Wert (man muss aber halt auch darin investieren) und geht nicht als "bloße" Chip Firma unter, siehe Imagination die ausgesaugt von Apple nun fallen gelassen wurden, oder zum Teil auch die Probleme mit denen AMD kämpft.

[StefanV]

CUDA is doch eher sowas wie 'nen Walled Garden.

Wenn wir ehrlich sind und nV nicht CUDA durchgedrückt hätte, wären sie seit einiger Zeit weg vom Fenster im Professionellem Bereich, da GCN hier einfach deutlich besser ist. Und Hawaii war auch einige Zeit lang deutlich besser im professionellem Bereich...

Und durch CUDA konnte nVidia quasi die Nutzer dazu 'erpressen', weiter ihre Produkte zu kaufen, die z.T. schlechter waren...

Und 3DFX Glide ist doch auch so ein Beispiel...
Auch das hat die Nutzer dazu gezwungen, 3DFX Hardware zu kaufen...
Was "bessere Treiber" und so angeht
Ist eigentlich ein Märchen und hauptsächlich darauf zurück zu führen, dass sehr früh sehr viele Software Hersteller eher auf nVidia Hardware getestet haben und sich 'nen Dreck um 'die anderen' geschert haben.

Ein umgekehrtes Beispiel dafür wäre die erste Version von Final Fantasy 7 und 8 auf PC, nicht die Steam Version. Das hat 'ne Patch für nVidia Hardware benötigt (keine Unterstützung für 8bit palletted Textures z.B.)
Das ist generell äußerst problematisch auf nVidia Hardware gewesen...

[aufkrawall]

Finde diese Fokussierung hier auf Cuda etwas seltsam, zumindest, wenn wir das aus Consumer-Sicht betrachten. Es interessiert mich persönlich eher wenig, was Firmen machen, und im Consumer-Bereich stagniert die Nutzung von Compute-APIs eher (ist zumindest mein Eindruck).

Viel nerviger finde ich, dass Nvidia Linux auf dem Desktop so torpediert: Kein GBM-Support, vdpau verschimmelt, vaapi wird nicht unterstützt, Fenster-Compositoren laufen meist wie Abfall und viele OpenGL-Spiele stottern entsetzlich (teilweise läufts mit Nouveau auf Kepler gar besser).
Das könnte mich als Kunde wirklich vertreiben, auch wenn ich mit der Treiber-Qualität unter Windows zufrieden bin.

[gravitationsfeld]

Alles was Niesche ist, wird bei NVIDIA stiefmuetterlich behandelt. Probier mal Optimus aus mit GL oder Vulkan auf Windows. Unfassbar.

[Iruwen]

Konkurrenz fördert Innovation. Wenn es keine Konkurrenz gibt, ist das Resultat halt Stagnation. Sieht man ja schön bei Intel. Ist dann halt nur doof, wenn plötzlich ein Underdog/Startup auftaucht und vorlegt, oder ein neuer Trend alte Märkte torpediert und man nicht früh genug reagiert hat, dann helfen einem u.U. auch die besten Patente nicht mehr. Sind ja schon genug Firmen von der Bildfläche verschwunden, die man zum Zeitpunkt ihrer Blüte als "too big to fail" bezeichnet hätte. Intel hat mit den Fabs usw. zumindest noch reelle Werte und könnte sich vermutlich "gesundschrumpfen", kA wie das bei NV aussieht.

/e: sorry, OT.

[deekey777]

https://twitter.com/DustinHLand/status/876937807331287040

Doom 3 BFG bekommt (irgendwann) einen inoffiziellen Vulkan-Renderer. Open Source und über Github.

No this is unofficial work. It'll go up on github as a fork of what was open sourced.

[iuno]

Mesa hat jetzt einen Workaround fuer einen glslang bug bekommen, der immer noch in DOOM und einem weiteren, nicht genannten (edit: im Kommentar steht Talos), Spiel haengt:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=1bd0acab21c250b263604a52ca6694941a6f02e0

Demnach kann man Doom vielleicht bald mit freien Treibern zocken... wenn auch natuerlich nur in WINE

[Ganon]

Man muss dazu erwähnen, dass man durchaus Kontakt mit den Entwicklern hatte, die davon wissen und man auf das nächste Update vertröstet wurde, was aber seit dem, innerhalb eines halben Jahres nicht erschienen ist.

Weiterhin ist es natürlich traurig, dass alle geschlossenen Treiber diesen Bug einfach kommentarlos durchwinken.

[aufkrawall]

Keine Sorge, unter Windows hatte man für Nvidia Grafikfehler reingepatcht, die auch nicht behoben wurden.

[Chris Lux]

Keine Sorge, unter Windows hatte man für Nvidia Grafikfehler reingepatcht, die auch nicht behoben wurden.
Man hat sogar allgemeine Graphikfehler reingepatcht - für alle Plattformen - die auch nie korrigiert werden.

[aufkrawall]

Diese Streifen mit der SSDO gibt es cross-platform? :freak:

[Chris Lux]

Diese Streifen mit der SSDO gibt es cross-platform? :freak:
Nein, aber die horizontalen Linien bei den Lens-Flares...

pJwwh_bipJ8

(@Coda: nein, ich will das jetzt nicht wieder hochkochen... totes Pferd und so ;))

[gravitationsfeld]

Man muss dazu erwähnen, dass man durchaus Kontakt mit den Entwicklern hatte, die davon wissen und man auf das nächste Update vertröstet wurde, was aber seit dem, innerhalb eines halben Jahres nicht erschienen ist.

Weiterhin ist es natürlich traurig, dass alle geschlossenen Treiber diesen Bug einfach kommentarlos durchwinken.
Patches muessen durch QA und Cert und kosten Geld und Zeit. Es wird keinen Patch geben solange nicht sowieso ein neues Release ansteht. Open-Source-Treiber auf einer nicht unterstuetzten Platform sind dafuer offensichtlich kein Grund.

Der Bug war zudem in Khronos-Compiler-Code in den fruehen Vulkan-SDKs, nicht in Doom.

Abgesehen davon schau dir mal den Patch an. Wegen den 10 Zeilen Code machen sie Seit einem Jahr einen Aufstand? Was zur Hoelle?

Keine Sorge, unter Windows hatte man für Nvidia Grafikfehler reingepatcht, die auch nicht behoben wurden.
Falsch. Die Artefakte sind sichtbarer unter Vulkan, aber sie existieren auch mit OpenGL. Und mit OpenGL hat sich durch Patches nichts geaendert.

Nein, aber die horizontalen Linien bei den Lens-Flares...

http://youtu.be/pJwwh_bipJ8

(@Coda: nein, ich will das jetzt nicht wieder hochkochen... totes Pferd und so ;))
Warum postet du es dann? Selbst wenn "die Entwickler" wollten wuerde sich daran nichts aendern. Das Problem wird nur von dir so hochgekocht. Ein Patch kostet zehntausende Dollar.

[Chris Lux]

Warum postet du es dann? Selbst wenn "die Entwickler" wollten wuerde sich daran nichts aendern. Das Problem wird nur von dir so hochgekocht. Ein Patch kostet zehntausende Dollar.
Wieder einen neuen User angelegt? ;D

OT:
Ja, ich ärger mich immer noch über die Artefakte - schlimm wenn es nicht so wäre. Diesmal war es jedoch nur auf Nachfrage... Vielleicht tut sich ja mit Doom VFR nochmal etwas. In den Videos waren ja die Hände mit dem Hologramm-Effekt zu sehen. Wenn da immer noch die Interferenzartefakte zu sehen sind kann das weh tun - ich denke aber, dass "die Entwickler" das im Griff haben werden.

[iuno]

Der Bug war zudem in Khronos-Compiler-Code in den fruehen Vulkan-SDKs, nicht in Doom.
Ist bekannt, wurde auch oben so geschrieben. Spielt aber im Grunde keine Rolle, weil der Bug schon ewig gefixt wurde und von DOOM an Kunden ausgeliefert wird und nicht von Khronos.

Abgesehen davon schau dir mal den Patch an. Wegen den 10 Zeilen Code machen sie Seit einem Jahr einen Aufstand? Was zur Hoelle?
Ich sehe keinen Aufstand. Wie du selbst sagst, ist die Plattform eh nicht unterstuetzt, die Treiber sind jetzt vielleicht gerade mal faehig, das Spiel ueberhaupt darzustellen, also ging in der Zeit ueberhaupt nichts verloren. Ausserdem halte ich das Vorgehen fuer vollkommen richtig, es ist eigentlich nicht deren Aufgabe die Fehler derer zu umgehen, die ihr Zeug verkaufen wollen. Und Treiber-Code (bei jedem vendor) kostet natuerlich nichts und muss nicht getestet werden oder was? :ulol:

[gravitationsfeld]

Open-Source-Treiber-Code auszuliefern kostet in der Tat nichts.

[iuno]

Erstens steht da extra "jeder Vendor", zweitens weisst du auch, dass das Unsinn ist.

[gravitationsfeld]

Was sind die Kosten? Die Internetrechnung fuer den Upload? Die 10 Minuten den Engineer zu bezahlen?

Mach dich nicht laecherlich.

Und nein, nicht "jeder Vendor". Der Fix ist im gemeinsamen SPIR-V-Code von Mesa. Das ist fuer jeden Treiber jetztigen und kommenden Treiber gefixt. Mit 10 Zeilen Code.

[iuno]

Also bitte, als waere es so stressig glslang zu updaten ;D Wenn das so ist, sehe ich nur eine Instanz die einen "Aufstand" macht und das ist lustigerweise auch noch die, die an der ganzen Sache Kohle macht und sonst keiner. Offensichtlich hat man da noch ganz andere Probleme als ein paar visuelle Fehler bei Nvidia.
Ich habe oben geschrieben dass der Code dort im Allgemeinen auch geschrieben und getestet werden muss. Das spielt aber natuerlich nur id eine Rolle aber nicht bei den Herstellern? Der von oben ist ein ganz normaler Treiberentwickler der bei Intel arbeitet, ist dessen Arbeitszeit weniger wert als die von sonst wem? Aber klar, wenn man nur einen Teilaspekt, die reine Auslieferung, rauspickt bei 3 Herstellern mit 5 Treibern hat man es natuerlich leicht zu argumentieren.
Und nein, nicht "jeder Vendor". Der Fix ist im gemeinsamen SPIR-V-Code von Mesa. Das ist fuer jeden Treiber jetztigen und kommenden Treiber gefixt. Mit 10 Zeilen Code.
Weiterhin ist es natürlich traurig, dass alle geschlossenen Treiber diesen Bug einfach kommentarlos durchwinken.
Aber ja, sind ja nur 10 Zeilen. Pflegen wird doch fuer jeden Bug auf Anwendungsseite einfach einen Workaround ein, den wir dann jahrelang mitschleppen.

[gravitationsfeld]

Also bitte, als waere es so stressig glslang zu updaten ;D
Ja. Ist es. Weil es kein Update gibt ohne vollen QA-Test. Das ist gaengige Praxis in allen grossen Firmen.

Das ist nicht wie in einer Indie-Bude wo man einfach mal eine neue Exe in Steam schmeisst. So laeuft es nicht.

Es gab auch genuegend Vulkan-SDK-Releases wo der Compiler SPIR-V-Code erzeugt hat der Bugs hatte und dann crasht es auf irgend welchen Treibern/Hardware/Windows-Kombinationen. Allein deshalb muss komplettes QA gemacht werden.

Der SPIR-V-Code ist auch in den Resource-Container-Files und wahrscheinlich ist das Update deshalb auch einige hundert Megabyte gross, weil es komprimiert ist und Steam das Delta nicht schnallt.

Ich finde das sind genuegend und ausreichend gute Gruende um nicht nur deshalb ein Update zu veroeffentlichen, welches einen Bug auf einer nichtunterstuetzten Platform behebt.

[iuno]

ja, das hattest du bereits gesagt.
Ich finde das sind genuegend und ausreichend gute Gruende um nicht nur deshalb ein Update zu veroeffentlichen, welches einen Bug auf einer nichtunterstuetzten Platform behebt.
Das hat auch niemand gefordert - zumindest nicht ich. Wenn du nachschaust war auch mein erster Beitrag zum Thema voellig ohne Wertung verfasst, ich fand es aber eine Anmassung zu schreiben, es wuerde seitens Mesa ein Aufstand gemacht werden. Ausserdem habe ich ein Problem mit der Eingrenzung auf Mesa und der Verschleierung der Problemursache, nur weil die anderen halt schon laenger einen Workaround drin haben.

[gravitationsfeld]

Du irrst dich, dass da nichts verloren ging. Mit RADV und dem Patch war es seit Monaten moeglich Doom zu spielen.

Ich hatte erwartet, dass der Fix ein groesseres Unterfangen ist so wie sie sich verhalten haben. Jetzt mit dem Patch zeigt sich mal wieder die Ideologie der Linux-Community. Hauptsache Recht haben, User sind egal.

Das zeigt sich auch wieder im Moment. Sie haben aus idologischen Gruenden die Aufnahme von AMD-Code im Kernel blockiert. Gibt es halt keinen Vega-Open-Source-Treiber zum Launch-Date. Sollen die User halt VESA-SVGA-Framebuffer benutzen.

[iuno]

Naja ich glaube nicht dass so viele zahlende user Kernel, WINE, radv usw. aus git bauen, neue GPUs haben und unbedingt das eine Spiel in WINE mit Vulkan spielen wollen anstatt wenigstens den offiziellen -pro Stack oder fuer Spiele einfach Windows zu nutzen.

Du hast das initiale DAL Patchset nicht angeschaut oder? Das hat mit einer besonderen Ideologie rein gar nichts zu tun, niemand der bei Verstand ist nimmt das einfach mal so auf. Zumal die Regeln voellig bekannt und klar sind, uebrigens auch den Entwicklern, aber irgendwer weiter oben musste ja so entscheiden.

Ausserdem ist die Info, dass es keinen freien Treiber zum Launch gibt, schlicht falsch, den gibt es genauso nur dass er halt nicht im Mainline Kernel ist. Was wiederum fuer die grosse Mehrkeit auch nichts gebracht haette, weil sie irgendwo bei Ubuntu und alten Kerneln haengen. Und wer Verrenkungen macht und unbedingt DOOM in WINE zocken will bekommt es auch hin automatisiert einen Kernel zu bauen. Das ist ungefaehr immer noch weniger Aufwand als man mit Nvidia auf hat.

[gravitationsfeld]

Q.e.d.

[iuno]

Darfst du Vermutungen aufstellen, ich aber nicht? Natuerlich habe ich keine Zahlen zu den Nutzern, die DOOM gekauft haben und keine andere Moeglichkeit haben (es geht um die Behauptung, dass "etwas verloren gehen" kann) das Spiel zu spielen. Ich bin persoenlich z.B. grosser Fan von freier Software, wuerde das Spiel aber trotzdem auf Windows spielen, nicht nur wegen FreeSync.

Oder was meinst du ueberhaupt genau? Der 4.11er Kernel ist in Alex Deuchers Branch inkl. DC (was DAL war) und Vega support, passende libdrm gibts auch dazu, Mesa (radeonsi und radv) Patches gehen schon upstream, es ist also alles da.

[Ganon]

Abgesehen davon schau dir mal den Patch an. Wegen den 10 Zeilen Code machen sie Seit einem Jahr einen Aufstand? Was zur Hoelle?

Was für einen Aufstand? Mesa hat nunmal die Prämisse gehabt, keine Workarounds für jede Anwendung zu implementieren. Darum laufen auch heute noch einige OpenGL Spiele nicht unter Mesa weil sie NVidiaGL nutzen und einfach keinen Spec-Konformen Code nutzen. Das ist aber kein Aufstand, sondern man hat schlicht gehofft, dass ein Fix doch noch mal kommt.

Heute ist's ein Workaround, morgen 100. Das ist doch einer der Gründe warum OpenGL da gelandet ist, wo es jetzt ist. Jede Anwendung benutzt irgend einen komischen Non-Standard Code und jeder Treiber macht Dinge irgendwo und irgendwie anders. Und auch aus dem Grund kracht's vermutlich auch bei vielen älteren DirectX-Anwendung, weil dann doch mal ein Workaround aus dem Treiber geflogen ist.

Dass in Mesa jetzt mal ein Workaround gelandet ist, ist hoffentlich nur eine Ausnahme, weil DOOM eben einer der wenigen Vulkan-Titel, gegen die es sich zu testen lohnt.

Das soll und darf einfach bei Vulkan nicht wieder so beginnen. Ob das nun an DOOM liegt oder an irgend einer Abhängigkeit. Wenn meine Anwendung wegen einer kaputten Lib nicht mehr funktioniert, kann ich auch nicht alle Browser-Hersteller dazu aufrufen bitte einen Workaround in ihren Browser einzubauen....

Klar, DOOM wird irgendwann mal gefixt, trotzdem ist es mir nicht egal wenn jeder Treiber einfach Bugs durchwinkt. Trotzdem vielleicht nicht annehmen, dass jetzt hier der totale Aufstand ist. ;)

Gibt es halt keinen Vega-Open-Source-Treiber zum Launch-Date. Sollen die User halt VESA-SVGA-Framebuffer benutzen.

Den gibt's doch jetzt schon. Ob der Mainline ist oder nicht, ist doch relativ egal. Mit dem geschlossenen Treiber habe ich auch nicht die freie Kernel-Auswahl.

edit: Mir ist auch klar, dass man als Spiele-Entwickler nicht so sehr auf Langzeit-Support ausgerichtet ist, da die Engines eh dauernd wechseln, abgelöst, eingestampft oder stark modifiziert werden. Aber gerade der OpenSource-Bereich hat dann doch etwas mehr Interesse an Langzeit-Support, das gilt auch für die Grafik-Treiber.

[aufkrawall]

Mit dem geschlossenen Treiber habe ich auch nicht die freie Kernel-Auswahl.

Ich bin kein Fan von proprietären Treibern unter Linux, aber mit dem Nvidia-Teil kannst du schon meist direkt mainline verwenden.

[Ganon]

Ich bin kein Fan von proprietären Treibern unter Linux, aber mit dem Nvidia-Teil kannst du schon meist direkt mainline verwenden.

Es ging mir jetzt um den AMD-Treiber. Aber hier (https://cgit.freedesktop.org/~agd5f/linux/) liegt der "AMD-Kernel", ist oft sogar ziemlich aktuell und enthält die vom Q&A abgesegneten Commits. Das meinte ich im Bezug auf "gibt's halt keinen OpenSource Vega Treiber"...

[aufkrawall]

Das ist das hier, richtig?
https://aur.archlinux.org/packages/linux-amd-staging-git/
Läuft das einwandfrei?

[Ganon]

Das ist das hier, richtig?
https://aur.archlinux.org/packages/linux-amd-staging-git/
Läuft das einwandfrei?

Ob das jetzt "einwandfrei" läuft kann ich dir nicht sagen, mangels eigener Erfahrung, aber es ist das, was auch im Mainline-Kernel landen würde, wenn man dahin commiten könnte.

[iuno]

Ja, ist der staging branch auf 4.11 (inkl. DC), inzwischen ist aber auch ein hybrid-branch und zugehoerige libdrm da mit den ioctls fuer Vulkan und OpenCL runtimes.

DAL hatte ich nur mal ganz kurz (ich brauche das ja ohne Vega nicht) vor einiger Zeit ausprobiert, wobei mir keine Probleme aufgefallen sind

[DevilX]

@iuno Aber nicht fertig als arch repository?

Ich würde gerne freesync meines Monitors nutzen.

[aufkrawall]

Du siehst doch den Link von mir ins AUR. Musst du selbst kompilieren, aber das geht mithilfe der Eingabe eines einzigen Befehls (bzw. mit Herunterladen und Installieren sinds dann halt drei, mit einem AUR-Helper wie pacaur wär es hingegen wirklich nur einer).

[DevilX]

Ja, ist der staging branch auf 4.11 (inkl. DC), inzwischen ist aber auch ein hybrid-branch und zugehoerige libdrm da mit den ioctls fuer Vulkan und OpenCL runtimes.

Hier drauf hab ich mich bezogen.
Wie ich aus dem AUR baue ist mir schon klar.

[aufkrawall]

Ups, ich hatte irgendwie "@Ganon" anstatt "@iuno" gelesen.

[iuno]

In den repos sowieso nicht, in den AUR glaube ich aber auch nicht. Brauchst du ein pkgbuild?
Wobei ich nicht sicher bin was man alles für freesync braucht, möglicherweise noch den ddx

[DevilX]

ein pkgbuild wäre super, aber villeicht sollten wir in den Linux thread wechseln.

Hab auch noch keine Infos gefunden was man alles bräuchte damit das läuft.

[iuno]

Da es recht kurz ist, um das abzuschliessen: Kernel mit DC und libdrm waeren bereit, es fehlt aber noch die Integration in Mesa. Wenn du also nicht sowieso den kompletten -pro stack nutzen willst mitsamt dem geschlossenen OpenGL Treiber, kannst du es (noch) nicht nutzen.
Edit: https://lists.freedesktop.org/archives/amd-gfx/2016-August/000917.html nicht mainline gegangen, weil die ioctl im mainline kernel fehlt (ist ja nur im hybriden Kernel) muesste man sich also nochmal anschauen...
Ausserdem ist alles amdgpu spezifisch, im Prinzip will man das aber auch wieder Vendor-uebergreifend haben. Intel hat ja auch angesagt, dass sie (irgendwann) mal adaptive sync unterstuetzen wollen - und wer weiss, vielleicht bekommen die Nouveau Jungs ja auch noch was hin ;)

Sorry fuer ot, das war es jetzt aber auch

[DevilX]

Danke, wieder etwas schlauer :-)

[aufkrawall]

Kurzer Benchmark Fusion BFE Windows 10 Redstone 2 vs. Linux 4.11, 384.76 & 384.47:

720p (upscaled, SSAO off):

Linux Vulkan:
https://abload.de/thumb/linux720pd0llp.png (http://abload.de/image.php?img=linux720pd0llp.png)
~325fps

Windows Vulkan:
https://abload.de/thumb/windows720p58zfh.png (http://abload.de/image.php?img=windows720p58zfh.png)
~301fps

Windows DX11:
https://abload.de/thumb/dx11720p4eyn7.png (http://abload.de/image.php?img=dx11720p4eyn7.png)
~255fps

4k (downscaled):

Linux Vulkan:
https://abload.de/thumb/linux4kkxa6b.png (http://abload.de/image.php?img=linux4kkxa6b.png)
89fps

Windows Vulkan:
https://abload.de/thumb/windows4kwrz92.png (http://abload.de/image.php?img=windows4kwrz92.png)
89fps

Windows DX11:
https://abload.de/thumb/dx114k8dykx.png (http://abload.de/image.php?img=dx114k8dykx.png)
98fps

[Locuza]

Danke für den Aufwand. (y)
Ein paar GPU-Optimierungen fehlen für den Gleichstand, aber immerhin tut es der CPU gut.
Wobei ich nicht (mehr) weiß, wie sich Talos Principle im Vergleich geschlagen hat.


Als kleine Randnotiz:
Changes and Fixed Issues in Version 384.76
[Doom 2016][Vulkan API]: Glitches occur when using the Vulkan API. [1935744]

http://us.download.nvidia.com/Windows/384.76/384.76-win10-win8-win7-desktop-release-notes.pdf

[aufkrawall]

Bei Talos war Vulkan unter Linux im GPU-Limit auch noch etwas langsamer als unter Windows. Ob das bei BFE Fusion nun aufgrund der Treiber oder Anwendung selbst anders ist, weiß ich nicht.
Der Vulkan-Renderer hat aber leider immer noch das Problem, dass das Kompilieren der Shader zur Laufzeit kurze Render Stalls verursacht.

[aufkrawall]

Es kommt bald ein weiterer Vulkan-Port von Feral für Linux:
http://phoronix.com/scan.php?page=news_item&px=RADV-Local-Shared-Var-Handling

Könnte RotTR sein.

[Kartenlehrling]

As part of our work on Vulkan gaming applications that are trying to solve these problems,
we’ve created a straightforward memory allocator for Vulkan that we’re continuing to develop.
It’s at the stage where we’d like to release it for you to start using it, while we continue to incrementally improve it and
think about integrating it with our other Vulkan technologies where we can.

Version 1.0 supports easy allocation of buffer and image storage out of larger allocated blocks,
and comes with a small sample that shows you how to use it.
The sample renders a cube with an index buffer, vertex buffer and texture, all allocated using the library.

Our plans for 2.0 and beyond include support for an allocation strategy that’s suitable for games that need to do texture streaming.

Please keep an eye out for future library updates.
http://gpuopen.com/vulkan-memory-allocator-1-0/

Das dauert mir einfach alles zu lang, ich hatte ja gehofft das DX11 in 5-8Jahre abgelöst wird,
wir können froh sein wenn in 10-15 Jahren kein neues Spiel mehr mit DX11 entwickelt wurde.

[gravitationsfeld]

10-15 Jahre. Klar. :rolleyes:

Das ist Beispiel-Code von AMD und hat nichts mit irgendwelchen Vulkan-Releases oder Planungen zu tun.

[aufkrawall]

Blizzard hatte 2015 HotS als DX9 only released, einige Entwickler werden sich wieder ewig Zeit lassen.

[Kartenlehrling]

Vulkan wird wohl für Mobil stärker unterstützt.

https://www.codeplay.com/portal/07-14-17-codeplay-release-clspv-an-opencl-tool-for-vulkan-enabled-devices
Codeplay Release “clspv”, an OpenCL Tool for Vulkan Enabled Devices

[pixeljetstream]

neue beta treiber mit vielen neuen extensions
https://developer.nvidia.com/nvidia-vulkan-developer-driver-khronos-vulkan-spec-update-1054
und noch slides von GTC wo einige der Khronos extensions noch experimentell waren
http://on-demand.gputechconf.com/gtc/2017/presentation/s7191-kubisch-esser-vulkan-technology-update.pdf

[pixeljetstream]

Vulkan wird wohl für Mobil stärker unterstützt.

https://www.codeplay.com/portal/07-14-17-codeplay-release-clspv-an-opencl-tool-for-vulkan-enabled-devices
Codeplay Release “clspv”, an OpenCL Tool for Vulkan Enabled Devices

der oben genannte vulkan beta treiber unterstützt alle notwendigen extensions für ocl -> vulkan spir-v

[Kartenlehrling]

Egosoft hat eine neue Version des Weltraumspiels X: Rebirth veröffentlicht.
Die VR Edition ist kein Update für die bestehende Fassung von Rebirth, sondern ein separates Steam-Spiel,
das ab heute für 40 Euro im Early Access spielbar ist und eine HTC Vive oder Oculus Rift benötigt - auch der Touch Controller wird unterstützt.

X Rebirth: VR Edition basiert inhaltlich auf bekannten Inhalten, die für die VR-Bedienung angepasst wurden.
Außerdem nutzt das Spiel eine neue, Vulkan-basierte Grafikengine, die auch bei X4 zum Einsatz kommen soll.
Die Entwickler versprechen deutlich bessere Performance,
die Optik selbst unterscheidet sich durch die neue Technik wohl aber nicht spürbar vom alten X: Rebirth, wie der VR-Trailer zeigt.


http://www.gamestar.de/videos/x-rebirth-vr-edition-release-trailer-jetzt-fuer-40-euro-im-early-access-gestartet-grafikengine-aus-x4,93926.html
X Rebirth: VR Edition - Release-Trailer: Jetzt für 40 Euro im Early Access gestartet; Grafikengine aus X4


Es ist natürlich auch auf dem Monitor spielbar.

Nahtloser Wechsel zwischen 3D und 2D - Das Benutzerinterface wurde speziell für den immersiven Einsatz der First-Person Perskeptive umgestaltet und
bietet volle Unterstützung der Oculus Touch und Vive Controller.
Spieler können dennoch nach Belieben jederzeit zwischen der Ansicht auf dem Monitor und den favorisierten Eingabegeräten umschalten.

[Ganon]

Dolphins neuste "Driver Hall of Shame" zeigt auch schön den aktuellen Stand der Intel Treiber:

https://dolphin-emu.org/blog/2017/07/30/ubershaders/

The Mesa driver does this and works very, very well in Vulkan Hybrid Ubershaders, where as NVIDIA only partially does and suffers from some stuttering at first.

[...]
Intel on Windows
The Vulkan driver only supports Skylake+, and is too buggy to be worth using currently.

[...]
Intel on Linux
The Anv driver is fantastic and should see the full benefits of Ubershaders.

[...]
AMD on Linux
radv behaves similar to anv and works quite well.


Ein paar Aussagen zu NVidia und AMD findet man dort auch, hauptsächlich aber mehr in Richtung "OpenGL vs. D3D". Der NVidia Treiber optimiert unter OpenGL wohl hier und da noch an den Shadern rum, was er unter D3D nicht tut. Ist in dem Fall nur leider kontraproduktiv.

Kann man nur sagen: Glückwunsch an das Intel Linux Team und den freiwilligen Entwicklern des OpenSource AMD Vulkan Treibers!

Fun Fact:
macOS Graphics Drivers are Still Terrible

:ulol:

[d2kx]

Ich bin ja mal gespannt, ob die Vulkan-Treiber für Mali/Adreno bessere Zustände erreichen als ihre traurigen OpenGL-Gegenspieler. Ich bin vorsichtig optimistisch, dass in den nächsten 12-24 Monaten viel passieren wird, wenn ChromeOS & Android mehr und mehr per default auf Vulkan setzen.

[gravitationsfeld]

Dolphins neuste "Driver Hall of Shame" zeigt auch schön den aktuellen Stand der Intel Treiber:

https://dolphin-emu.org/blog/2017/07/30/ubershaders/



Ein paar Aussagen zu NVidia und AMD findet man dort auch, hauptsächlich aber mehr in Richtung "OpenGL vs. D3D". Der NVidia Treiber optimiert unter OpenGL wohl hier und da noch an den Shadern rum, was er unter D3D nicht tut. Ist in dem Fall nur leider kontraproduktiv.

Kann man nur sagen: Glückwunsch an das Intel Linux Team und den freiwilligen Entwicklern des OpenSource AMD Vulkan Treibers!

Fun Fact:


:ulol:
NVIDIA macht constant folding in OpenGL, d.h. wenn es an/aus Optionen von Uniforms detektiert erzeugt es verschiedene Shader anstatt den Branch in Hardware auszufuehren.

Ich bin ja mal gespannt, ob die Vulkan-Treiber für Mali/Adreno bessere Zustände erreichen als ihre traurigen OpenGL-Gegenspieler. Ich bin vorsichtig optimistisch, dass in den nächsten 12-24 Monaten viel passieren wird, wenn ChromeOS & Android mehr und mehr per default auf Vulkan setzen.
Vulkan ist von Treiberseite aus viel einfacher zu implementieren als OpenGL. Vor allem fuer TBR-Chips.

[d2kx]

Khronos Announces the Vulkan Portability Initiative (https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative)
Khronos

Khronos Releases OpenGL 4.6 with SPIR-V Support (https://www.khronos.org/news/press/khronos-releases-opengl-4.6-with-spir-v-support)
Khronos

[Ganon]

Khronos Announces the Vulkan Portability Initiative (https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative)
Khronos

Das war ja abzusehen. Klingt jetzt natürlich ideal nach "There are 14 competing standards...", aber ist ja nun leider nötig, da Microsoft und Apple sich ja mehr oder weniger quer stellen. Der eine sagt "Store Apps nur DX12", der andere sagt "Vulkan is nich"...

Mal schauen wie viel Anklang das findet, wenn es denn mal fertig ist. Darf halt unterm Strich nicht viel langsamer sein als wenn man DX12 oder Metal direkt benutzt.

[Achill]

Khronos Announces the Vulkan Portability Initiative (https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative)
Khronos
[..]


Das war ja abzusehen. Klingt jetzt natürlich ideal nach "There are 14 competing standards...", aber ist ja nun leider nötig, da Microsoft und Apple sich ja mehr oder weniger quer stellen. Der eine sagt "Store Apps nur DX12", der andere sagt "Vulkan is nich"...

Mal schauen wie viel Anklang das findet, wenn es denn mal fertig ist. Darf halt unterm Strich nicht viel langsamer sein als wenn man DX12 oder Metal direkt benutzt.

Und der Layer sollte OpenSource sein, damit nicht jeder Hersteller wieder beginnt seine eigene Implementierung inkl. eigener Interpretation zu liefern.

[Ganon]

Dass es Open Source ist und auf github entwickelt wird, steht ja im Artikel.

[Achill]

Dass es Open Source ist und auf github entwickelt wird, steht ja im Artikel.

mea culpa

[Loeschzwerg]

Wie ist denn der Status bezüglich AotS @ Vulkan?

Jemand hierzu neue Infos?

[dargo]

Ich klinke mich mal ein... gibts schon ungefähren Termin für den Vulkanrenderer für Deus Ex? :)

[Entropy]

Ich bin ja mal gespannt, ob die Vulkan-Treiber für Mali/Adreno bessere Zustände erreichen als ihre traurigen OpenGL-Gegenspieler. Ich bin vorsichtig optimistisch, dass in den nächsten 12-24 Monaten viel passieren wird, wenn ChromeOS & Android mehr und mehr per default auf Vulkan setzen.
Treiber werden einfacher, die Gesammtsituation wird schlechter, denn was Treiberteams nicht hinbekommen haben, wird in den Händen der einzelnen Devs liegen.
Bei OpenGL hast du schon öfter, dass alte Software meint, dass deine neuste GPU nicht kompatibel ist, weil die Hardware zur Zeit als die Software geschrieben wurde noch nicht existierte.
Bin gespannt, ob die Spielehersteller ihre alten Vulkan und Direct3D 12 Spiele für neuere Hardware, falls Probleme auftauchen, patchen.

[Loeschzwerg]

Hm... RX480 @ BF4 @ Mantle lief ja nicht sonderlich gut (meine da zumindest mal was gelesen zu haben), wurde dies eigentlich behoben? Das fällt doch genau in diesen Bereich.

[captain_drink]

Hm... RX480 @ BF4 @ Mantle lief ja nicht sonderlich gut (meine da zumindest mal was gelesen zu haben), wurde dies eigentlich behoben? Das fällt doch genau in diesen Bereich.

Nö

[Ex3cut3r]

Ich klinke mich mal ein... gibts schon ungefähren Termin für den Vulkanrenderer für Deus Ex? :)

Wieso sollte da noch was kommen?

Hat doch schon Low Level mit DX12, wie ist der eigentlich der aktuelle Stand? Bringts da etwas im CPU/GPU Limit?

[dargo]

Wieso sollte da noch was kommen?

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11196517&postcount=1891

[Fragment]

Immer her mit den Vulkan-Implementierungen.
Kann die Minimums und Averages von 120+ FPS wie in Mad Max oder Doom in jedem Game gebrauchen :)

[Kartenlehrling]

Wird das Shader Model 6.0 eigentlich auch unter Vulkan genutzt oder ist das eine reine Microsoft Geschichte?
In der Unreal Engine ist es wohl unter Vulkan erstmal nur Shader Model 5.0 als Standard. :confused:

https://pbs.twimg.com/media/DGQ6yXIVwAEL8Xh.jpg:large

[kruemelmonster]

Jemand hierzu neue Infos?

Warte auch schon einige Zeit, zum Glück ist es auch ohne Vulkan schon ein gutes Spiel und nicht nur ein Benchmark.

Möglicherweise sehen wir das AotS Vulkan Release wenn der aktuelle NV Dev Treiber r382.88 in den Mainbranch eingepflegt wird:
Windows driver version 382.88 and Linux driver version 381.26.11 provide new features for Vulkan developers to test their upcoming Vulkan applications.

We are in the final stages of Vulkan testing. We have Vulkan working but we are working with the driver makers to iron things out. Nothing comes close to pushing Vulkan like Ashes.

We were hoping to get Vulkan support included with the June patch for episode 3, but unfortunately it's being delayed to a later date. Draginol: "The NVIDIA dev team has been at the office all week helping us optimize Vulkan support for Ashes. We'll likely have to time our release on the Vulkan version with when NVIDIA and AMD have their driver updates that support the parts of Vulkan we're using." :freak:


[ETA for Vulkan] Most likely August.

[DanMan]

Khronos haben ihre Vorträge zur diesjährigen SIGGRAPH auf YT geladen. Dabei unter anderem das hier über Vulkan: https://www.youtube.com/watch?v=bjE-sCkgC7o&list=PLYO7XTAX41FMmwf1i4JdDkjc0nbgxz5Fh&index=1

[Locuza]

In der Unreal Engine ist es wohl unter Vulkan erstmal nur Shader Model 5.0 als Standard. :confused:
[BILD]
Das Shader Model gilt sowieso nur für DX, er verwendet es nur als funktionellen Richtwert.
Wie die Folie schon angibt, war der Vulkan-Renderer vorher nur bei ~SM4.0 ohne Compute-Shader.
SM6.0 bringt Cross-Lane-Operations, dass müsste die UE4 auch erst einmal umsetzen und ähnliche Funktionalität wird es als Erweiterungen für Vulkan geben.

Khronos haben ihre Vorträge zur diesjährigen SIGGRAPH auf YT geladen. Dabei unter anderem das hier über Vulkan: https://www.youtube.com/watch?v=bjE-sCkgC7o&list=PLYO7XTAX41FMmwf1i4JdDkjc0nbgxz5Fh&index=1
Ich habe es mir gestern angesehen, weswegen nur mein Alzheimer für mich sprechen kann, aber folgende Dinge waren interessant:

- Mobile OGL ES 3.2 hat eine relativ geringe Verbreitung und es gibt keinen großen Unterschied zum Vulkan-Support, was die Masse angeht.

- Eine neue Core-Spec von Vulkan befindet sich in Arbeit, möglicherweise für das nächste Jahr?

- Codeplay hatte das Projekt OpenCL C Code in Vulkan auszuführen näher beleuchtet.
Adobe hat ihnen 200K an Codelines von ihren Produkte gegeben und nur ungefähr 30 mussten geändert werden, bevor die Compiler-Pipeline funktioniert hat.
Dafür waren auch zwei neue Erweiterungen wie FP16 Storage und eine für die Pointer notwendig.

Es macht Hoffnung, dass die Verschmelzung von Vulkan und OpenCL umsetzbar ist und in "naher" Zukunft stattfinden kann.

- LunarG hat den SPIR-V Vorgang effizienter gestaltet, der Bytecode ist weniger als die Hälfte so groß und fällt damit auch weniger als die Hälfte größer, gegenüber DX aus.

- UE4 denkt darüber nach Vulkan als Default-Renderer für Vulkan einzusetzen, es ist aktuell glaube ich OGL 4.3.

Aktuell läuft Vulkan grob auf dem Niveau von DX11, +/- 10%.
Das liegt natürlich daran, dass noch viele Optimierungen fehlen, dazu gehört auch der Kernaspekt des Multi-Threadings, der Renderer verwendet scheinbar nur einen Thread.
Nachdem man das umstellt erwartet man 50-60% bessere Performance.
Ach ja, sie finden den Radeon-GPU-Profiler super cool und arbeiten damit ihre Umsetzungen zu verbessern, auch Async Compute wollen sie besser ausnutzen.

Es gab natürlich noch mehr Infos, auch zu OGL, OGL ES, LunarG Projekten und die Möglichkeit ein funktionell schwächeres Gerät zu simulieren, HLSL zu SPIR-V Neuigkeiten bzw. Statusupdates.

[Kartenlehrling]

https://t.co/Z7pqMsEBwV
future directions for compute-for-graphics / Andrew Lauritzen

http://www.joshbarczak.com/blog/?p=1317
Comments on Future Directions for Compute in Graphics / Josh Barczak

[deekey777]

Freiwillige?
https://github.com/DustinHLand/vkDOOM3

[SaschaW]

Kompiliert und läuft :)

[SaschaW]

Wer Benchmarken will: Ich habe grade einen commit gepusht (https://github.com/DustinHLand/vkDOOM3/commit/2e84e58d5111ca14043a45504fa935915fd498f3) mit dem sich auch unter Vulkan V-Sync deaktivieren lässt (via r_swapInterval). Alles jenseits von 60/120 fps sorgt dafür dass das Spiel auch schneller läuft (die Spiellogik ist darauf festgelegt), d.h. man muss das Limit in der Konsole via "com_fixedtic -1" deaktivieren damit man auch im Spiel über 60/120 fps kommt.

[Kartenlehrling]

X Rebirth VR / X4 Erste Einblicke
Neue Grafik-Engine – Die X Rebirth VR Edition wird der erste Egosoft-Titel sein,
der unsere neue Entwicklung nutzt, die auf der innovativen neuen Grafiktechnologie Vulkan basiert.

[Nur Presse]
Mi 23. Aug 14:00 @ GamesCom, Köln (private Vorführung auf der GamesCom in Köln, nur mit Fachbesucherausweis!)
Do 24. Aug 15:00 @ GamesCom, Köln (private Vorführung auf der GamesCom in Köln, nur mit Fachbesucherausweis!)


Sa 26. Aug 17:00 @ Egosoft HQ, Würselen (Präsentation, Fragestunde und Party bei EGOSOFT in Würselen)
So 27. Aug 13:00 @ Egosoft HQ, Würselen (Präsentation, Fragestunde und Party bei EGOSOFT in Würselen)
https://www.egosoft.com/x4/signup_de.php

[deekey777]

Kompiliert und läuft :)
War das Kompilieren kompliziert? Bzw. was muss ich alles herunterladen?

[SaschaW]

War das Kompilieren kompliziert? Bzw. was muss ich alles herunterladen?

Es gibt inzwischen auch vorcompilierte Binaries: https://github.com/DustinHLand/vkDOOM3/releases

Da fehlen dann u.U. die jeweils neusten Codeänderungen. Das Projekt kompiliert aber out-of-the box. Wenn man die Community Edition vom VS nutzt muss man noch entweder MFC mit/nachinstallieren oder in der doom.rc den afxres.h Header durch den windows.h Header ersetzen.

[deekey777]

Es gibt inzwischen auch vorcompilierte Binaries: https://github.com/DustinHLand/vkDOOM3/releases

Da fehlen dann u.U. die jeweils neusten Codeänderungen. Das Projekt kompiliert aber out-of-the box. Wenn man die Community Edition vom VS nutzt muss man noch entweder MFC mit/nachinstallieren oder in der doom.rc den afxres.h Header durch den windows.h Header ersetzen.
Das ist ja genial, werde heute Abend ausprobieren. Danke.


Ich hab's ausprobiert. Wichtig: Sprache muss auf Englisch sein. Und mit der Exe läuft das Spiel sehr scharf, es gibt aber mindestens einen Fehler, die Fensterscheiben sind durchsichtig.

Aber woran erkenne ich, dass das Spiel wirklich mit Vulkan läuft? MSI Afterburner? Aber der RivaTuner Server wollte nicht laufen (Kompatibilitätsmodus?).

Dann eben so:
https://abload.de/thumb/doom3_bfgedition15.08nea6p.png (http://abload.de/image.php?img=doom3_bfgedition15.08nea6p.png)

[Demogod]

auflösung ändern geht bei mir nicht ->crash (per ini noch nicht versucht)
getestet mit v092
hw in userinfo. crimson 17.7.2

[deekey777]

auflösung ändern geht bei mir nicht ->crash (per ini noch nicht versucht)
getestet mit v092
hw in userinfo. crimson 17.7.2
Geht bei mir auch nicht. Lösche die kopierten Dateien (wenn's noch geht, Kopieren rückgängig machen), lasse Steam die fehleden Dateien nachladen, ändere die Einstellungen, wie du es haben willst, beende das Spiel und Steam (Steam muss nicht gestartet werden) und füge erneut die angepasste EXE und den Base-Ordner ein.

Mit der Exe sieht das Spiel sehr scharf aus, es gibt nicht diese komische Runterskalierung. Ab und zu fällt die Bildrate auf unter 40, aber sonst sind es 60 FPS (com_showFPS 1). Ich spiele auf meinem Laptop mit A10-9600P, also 6 CUs.

[Demogod]

hat geklappt..
also das setzen der auflösung mit der originalen exe und dann wechseln zur vulkan exe
können auch beide coexistieren, da der vulkan kram nichts ersetzt hat

[Locuza]

Nach langer Zeit gibt es endlich einen offiziellen Termin für den Vulkan Patch für Ashes of the Singularity mit Patch 2.4 am 24 August:
Major v2.4 Update, Free DLC, and Vulkan Support for Ashes of the Singularity: Escalation Coming on Aug. 24
Vulkan Support: Vulkan is a graphics-rendering API that offers enhanced OS compatibility and performance. Some of the benefits include reduced CPU load time and the ability to work on other tasks, plus CPU scaling that takes advantage of multiple cores. Vulkan also runs on different OSes (Windows 7, 8, 10), and still receives all of the advantages as if it were running on the latest OS.
https://forums.ashesofthesingularity.com/484537

[dargo]

Bin schon gespannt. =)

[Loeschzwerg]

Endlich :) Mal schauen ob Vulkan besser läuft als DX12 @ Intel IGP ^^

[SaschaW]

Endlich :) Mal schauen ob Vulkan besser läuft als DX12 @ Intel IGP ^^

Vulkan auf Intel IGP unter Windows kann man eigentlich komplett vergessen. Der Treiber ist seit ewig beta und hinkt dem ziemlich guten Linux Intel IGP-Treiber komplett hinterher. Was Vulkan unter Windows angeht ist Intel eine totale Enttäuschung.

[Achill]

Wir haben schon getestet ... geht hier los: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11461837#post11461837

[IchoTolot]

Talos Principle unterstützt btw. auch Vulkan wie ich gerade sehe. Hab es eben endlich gekauft und grade installiert.

https://lh3.googleusercontent.com/J_WH-MUX_JlcQYVIQjbHWNuoH0yXzT2Xnt-YIzSbI7H5okXMJHaGbEeqJ5zy05CoLvd84OU_RdEXZJGm8Ldb7JyuD9TMLBIWV4b9xAKax9el5ewesgt 9z5ANgKtnsWzhidJFpc7nG5hycGthxIaS7tyyRYc7iH-skRURfvW2bSw3y_kMYf-bTxRmjQmcRCSHJg1hZYbMvtqA4eihwR_wx61QgKnyWSChlGFNeFTtJMxhLQQHaYspYd9UNT41_J1RMKp BNsnGke5kskwdoha_F63WigXpJvh3jBDEulX60ozXsNdyqbX2oraZF1A5UELLnrwbh_jK3tszVzyP3N6 zQfC0Jb_0txI1qwnQvLiM9NDjtXUEVG2-YWGfIkgU7Xmkkz9wUaXXqRi-IOmgF_-5bo5Rt8KZYkNE6q_2nH_3ueuTG18AUuKUJq_-hMVFklE4da0oX3V4DOPoau0kVd0uh_8uXilL7Czk6gXnB43po7631vHF3JmvMZ6_mKEmgWevFdVkRdFZ SHx2dDAWl_0brDIc_0YlrLX7aQ92_2yE3sojkk11jlk2ZdoEf4ISOMa4oA7E5mRuvCyQZkhbSutgUkwf 1hS0FHzLrNi6z7guGOYp8astoXMK4g=w1743-h981-no

[aufkrawall]

Das wissen wir schon lange. Talos nutzt aber nicht die neuste Engine-Version (im Gegensatz zu Fusion) und auch bei Fusion ist Vulkan bisher nur das kleinere Übel gegenüber dem OGL-Pfad für Linux.

[Troyan]

Futuremark hat für die Android-Version des 3DMark Vulkan beim API-Test hinzugefügt. Mein Shield TV erreicht folgendes:
OpenGL ES 3.0: 158.118 Drawcalls per second (30FPS)
Vulkan: 2.368.282 Drawcalls per second (30FPS)

Keine Ahnung, wie vergleichbar die Android-Version mit dem PC ist. Aber das Vulkan-Ergebnis entspricht im Grunde DX11 mit einer 8K/16T CPU und Geforce-Karte: http://www.guru3d.com/news-story/quick-test-futuremark-3dmark-v2-3-3663-vulkan-api-overhead-benchmarks.html

Finde ich beeindruckend. Shield TV kann nur die 4x A57 Kerne verwenden.

[dargo]

Was meinen die Profis (falls überhaupt einer darüber reden darf :D)?
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11465750&postcount=100

[N0Thing]

Dürfte eine unglückliche Aufzählung sein, bei den anderen Medien ist nur von Rapid Packed Math für Far Cry 5 die Rede.

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/News/AMD-Wolfenstein-2-Vulkan-FP16-Far-Cry-5-1234667/

m Werbevideo zum Marketing-Begriff Rapid Packed Math verrät AMD darüber hinaus, dass Far Cry 5 FP16-Berechnungen nutzen wird. Für welche Effekte die Studios auf FP16 ausweichen werden, ist noch nicht bekannt.

[Naitsabes]

Shield TV (Tegra X1)
4*Cortex A57 @ ~1.90GHz
256 SP Maxwell (v2?) @ ~1GHz

OpenGL ES 3.0: 158.118 Drawcalls per second (30FPS)
Vulkan: 2.368.282 Drawcalls per second (30FPS)

Faktor: ~15


Shield Tablet (Tegra K1)
4*Cortex A15 @ ~2.2GHz
192 SP Kepler @ ~852MHz

OpenGL ES 3.0: 140.195
Vulkan: 1.876.388
Faktor: ~13



Oneplus 3 (Snapdragon 820)
2*Kryo LP @ ~1.6GHz
2*Kryo HP @ ~2.15GHz
Adreno 530 @ ~624MHz

OpenGL ES 3.0: 82.693 Drawcalls per second (30FPS)
Vulkan: 505.504 Drawcalls per second (30FPS)
Faktor: ~6


Die Leistung vom Tablet finde ich noch beeindruckender. Schließlich stehen da nur 4 A15 zu Verfügung.
Bei Qualcom bringt Vulkan zwar auch schon einiges, aber der Treiber scheint auch da noch viel Potential zu besitzen.

[vinacis_vivids]

CRYENGINE 5.4@Vulkan
https://www.cryengine.com/news/cryengine-54-major-release

[aufkrawall]

mpv kann jetzt Vulkan:
https://github.com/mpv-player/mpv/commit/91f23c7067af248846420854a0dc78c26ea6e300
Cool, aber imho eher langfristig für Android interessant.

[aufkrawall]

Nun in vorkompilierten Nightly Builds verfügbar:
https://sourceforge.net/projects/mpv-player-windows/files/64bit/
Funktioniert hier auf Nvidia sogar schon besser als OpenGL, hab leicht niedrigere CPU-Last und die GPU taktet schneller runter (d3d11va-copy).
Falls aber auch in Zukunft kein zero copy D3D11VA damit möglich sein sollte, wär DX11 für das Programm auf Windows klar besser (soll mit dem neuen abstrahierten Renderer wohl auch kommen). Außer natürlich, Multi Queue quetscht aus einer GPU-Architektur noch ordentlich Leistung raus. ;)

[Tesseract]

mit welchen launch options läuft das?

[aufkrawall]

Steht bereits in der gitmaster manpage:
https://mpv.io/manual/master/

Eine Beispielconfig mit etwas GPU-Belastung ohne HW-Decoding:

gpu-api=vulkan
dither-depth=8
sigmoid-upscaling
correct-downscaling
cscale=ewa_lanczossharp
scale=ewa_lanczossharp
tscale=sinc
video-sync=display-resample
interpolation
deband

Etwa in einem Unterverzeichnis "mpv" als "mpv.conf" platzieren.

[aufkrawall]

Hab nochmal etwas Zeit und Schmerzen in Doom Vulkan auf Linux mit meiner 250GB SSD Multiboot Windows + Arch (Linux 4.13, Nvidia 384.90, wine-staging-git) investiert. :D
Hat sich gelohnt: Die fiesen Frametime-Spikes, die ich letztes Mal hatte, sind komplett weg (kann allerdings auch am Wechsel von Sandy Bridge -> Skylake liegen), es fühlt sich perfekt flüssig an und läuft aus der Erinnerung ca. gleich schnell wie unter Windows.
Nach den ganzen technisch oder grafisch durchwachsenen Vulkan-Ports, die für Linux verfügbar sind, ist das echt mal ein schönes Erfolgserlebnis -> kein verdammtes Stuttering! Mal sehen, ob sich das mit OBS auf Video festhalten lässt.
Würde doch einfach jedes Spiel so unter Linux laufen...

Der neue 387.12 Nvidia-Treiber scheint aber nur jedes 2. Frame darzustellen, die im Changelog angeführte Neuerung für Vulkan + X11 Flipping hat da wohl eine unschöne Nebenwirkung...

[Gast]

Nvidia läuft bei LL-API durch die Bank generell sehr sehr bescheiden, da hilft nur eine rund erneuerte uArch mit entsprechender Implementierung in der Hardware.

[Kartenlehrling]

John Carmack will selbst optimieren - »Grafiktreiber-Programmierer machen oft Fehler«

Neue Grafikkarten-Treiber bereiten John Carmack anscheinend öfter Probleme,
daher bittet er darum, ihm die Low-Level-Optimierung für VR zu überlassen.

http://www.gamestar.de/artikel/john-carmack-will-selbst-optimieren-grafiktreiber-programmierer-machen-oft-fehler,3320956.html

[Kriton]

Das bezieht sich aber IMHO unmittelbar (nur) auf Oculus.

[Gast]

Das bezieht sich aber IMHO unmittelbar (nur) auf Oculus.

Was er sagt, lässt sich auf alles Codes übertragen. Dass es auf Oculus bezogen ist, ist lediglich ein Spezialfall.

[iuno]

F1 2017 nutzt, wohl etwas ueberraschend, Vulkan (Linux): https://twitter.com/feralgames/status/923977346561998848

[dargo]

Warum denn nur Linux? :freak:

[iuno]

Die Frage sollte man Codemasters oder wer auch immer die Windows Version gemacht hat stellen. Ist ja leider auch nichts neues, dass die einen Scheiss darauf geben, auch wenn es ein Multi Titel ist.

[dargo]

Naja... von denen kommt eh jedes Jahr ein neues F1. :freak: Vielleicht klappts ja endlich mit F1 2018 für Windows. :D

[Grendizer]

Naja... von denen kommt eh jedes Jahr ein neues F1. :freak: Vielleicht klappts ja endlich mit F1 2018 für Windows. :D

Vieleicht wird es ja für Windows nachgepatched. Wäre interessant, wenn man dann die APIs vergleich könnte.

Oder ich schmeiss mal wieder ein Mint auf eine Platte und teste selber.

[DanMan]

Vieleicht wird es ja für Windows nachgepatched. Wäre interessant, wenn man dann die APIs vergleich könnte.
Wurde bei Mad Max auch nicht gemacht, würde mich also wundern. Hat ja Feral nix von.

Ich glaube auch nicht, dass das ganze Spiel wirklich auf Vulkan läuft, sondern nur die Übersetzungsschicht für D3D.

[dargo]

Aber immerhin beschäftigt sich Codemasters schon mal mit Vulkan offiziell. Ein kleiner Schritt nach vorne.

[aufkrawall]

Aber immerhin beschäftigt sich Codemasters schon mal mit Vulkan offiziell.
Wie kommst du denn darauf? Den Port macht Feral, nicht CM.

[iuno]

Vieleicht wird es ja für Windows nachgepatched. Wäre interessant, wenn man dann die APIs vergleich könnte.
Das ist glaube ich noch bei keinem Titel passiert, der von einem Drittstudio portiert wurde.

Wuerde ja auch wenig Sinn machen. Erst bezahlt man fuer den Windows Port, dann jemand anderen fuer den Linux Port, dann soll man beide nochmal dafuer bezahlen um den Windows-Port umzuschreiben? Entweder kommen die endlich mal auf den Trichter und machen es von Anfang an richtig, oder die Trennung bleibt bestehen.

[DanMan]

https://www.gamingonlinux.com/articles/f1-2017-released-for-linux-as-feral-interactives-first-vulkan-only-title-heres-a-port-report.10652

Sehe mich bei der Leistung in meinem Verdacht bestätigt, dass das nur ein Vulkan Wrapper um das D3D Spiel ist. Alles andere wäre wohl auch zu aufwändig.

[iuno]

Phoronix hat jetzt auch (NV) Benchmarks: https://www.phoronix.com/scan.php?page=article&item=f1-2017-nvidia
Nichts neues also. Mich interessiert vor allem, ob und wie das Spiel mit Mesa Treibern laeuft.

Was stimmt eigentlich mit dem Spiel nicht? Da ist das Bild mind. 6x zerrissen und das bei bei 53 FPS :confused:
http://www.phoronix.net/image.php?id=f1-2017-nvidia&image=f12017_nv_1_show

[Ganon]

Phoronix so "no rendering issues"... und zeigt 3 Screenshots mit richtig fetten rendering issues :ugly: Der Zaun sieht ja mal richtig kaputt aus... im 3. Screenshots fliegt das Zeug auch einfach mal diagonal in die Luft.

Vermutlich hat aber Phoronix einfach nur sehr schlechte Screenshots gemacht. Der Typ ist ja nicht gerade der Kompetenteste in seinem Fach.

Sehe mich bei der Leistung in meinem Verdacht bestätigt, dass das nur ein Vulkan Wrapper um das D3D Spiel ist. Alles andere wäre wohl auch zu aufwändig.

Nur weil etwas Vulkan / DX12 benutzt, heißt das nicht automagisch, dass es dann auch unbedingt schneller laufen muss. Es gibt 1000 Wege wie Vulkan-Code verdammt langsam werden kann. Ich schließe zwar einen Wrapper nicht unbedingt aus, aber alleine schlechtere Performance ist keine Garantie dafür.

[aufkrawall]

Das ominöse Tearing auf den Bildern würd ich nicht überbewerten, vielleicht hat er die Bilder irgendwie seltsam gecaptured. Wenn bei Nvidia Vulkan-UIs unter Xorg mit Compositor-Vsync laufen, gibt das auch so kaputtes Ekeltearing, solange man nicht Vsync in der Anwendung aktiviert. Mit Gnome 3.26 war auch das Abschalten vom Compositor für Vollbild-Anwendungen teilweise kaputt, das wurd aber zum Glück mit 3.26.2 gefixt.
afaik kann man mit Spectacle unter Plasma Xorg ganz normal Screenshots von Vulkan-Anwendungen im Vollbild ohne Tearing machen. Phoronix-Michael Mysteries *shrug*.

Zum Test von GoL: Scheint nach üblem CPU-Limit auszusehen, vielleicht wärs mit einem Consumer-Intel mit 4C besser. Aber die fps sind ja sehr hoch. Falls die Frametimes nicht mies sind, wär das ja auch noch ok. Ich hab genug OGL-Ports gesehen, die wie ein Haufen Mist stottern.

[iuno]

Offenbar wurde bei phoronix auch noch mit voellig falschen settings gemessen... :rolleyes: https://github.com/phoronix-test-suite/test-profiles/pull/7

[aufkrawall]

Das passiert wohl, wenn man zwischendurch noch lauter nichtssagende Bullshit-Tests mit drölfzig GPUs in völlig nichtssagenden Anwendungen vornimmt. :uup:

[Ganon]

Auch wenn Phoronix mal mehr oder weniger sinnvolle Benchmarks macht, muss man diese mit sehr viel Vorsicht genießen. Große Ausreißer bleiben unkommentiert, teilweise fehlende Ergebnisse werden verschwiegen und hingenommen und Messfehler sind eher die Regel bei Phoronix. Alles begleitet mit dem "Pay me" Kommentar.

Als News-Feed ist die Seite ganz brauchbar, aber Benchmarks abseits von "Feature On vs Feature Off" sind in der Regel für die Tonne.

[DanMan]

Nur weil etwas Vulkan / DX12 benutzt, heißt das nicht automagisch, dass es dann auch unbedingt schneller laufen muss. Es gibt 1000 Wege wie Vulkan-Code verdammt langsam werden kann. Ich schließe zwar einen Wrapper nicht unbedingt aus, aber alleine schlechtere Performance ist keine Garantie dafür.
Wenn Doom sogar unter Wine+Vulkan quasi identisch schnell wie unter Windows läuft, warum soll es dann nativ schlechter sein?

Nene, das ist garantiert nur mit Wrapper umgesetzt, wie eigentlich alle D3D Ports, oder hab ich was verpasst? Feral schreibt ja nicht mal eben die ganze Engine um. Das lohnt sich doch finanziell gar nicht.

[Ganon]

Wenn Doom sogar unter Wine+Vulkan quasi identisch schnell wie unter Windows läuft, warum soll es dann nativ schlechter sein?

Es geht nicht um den Vulkan-Treiber sondern um den Gamecode. Nur weil ein Spiel jetzt die Vulkan-API verwendet, heißt das nicht, dass es plötzlich allem überlegen ist. Es ist sogar sehr sehr simpel durch ungünstige Zustände sehr viel Performance zu verlieren.

Die Aussage hier ist auch nicht, dass es kein Wrapper ist, sondern eben nur, dass die verwendete API nichts über die Performance aussagt.

Aber nehmen wir mal einfach an, dass die Engine halbwegs ordentlich entwickelt ist. Dann hat das Spiel an einer bestimmten Stelle den Code, der eben den Kram über DX11 rendert. Wenn Feral jetzt einfach diesen Code durch Vulkan-Code ersetzt, dann läuft es ohne Wrapper direkt über Vulkan. Es kann aber durchaus sein, dass die Art und Weise wie das Spiel allgemein rendert über Vulkan eben nicht so tolle funktioniert. Hinzu kommt vermutlich auch noch mangelnde Erfahrung mit Vulkan allgemein.

Spätere Patches könnten die Performance vielleicht auch noch steigern. Für Linux ist erst mal die Nutzung von Vulkan schon wichtig genug. Es gibt bei OpenGL einfach so viel Legacy-Scheiße, "NvidiaGL" und unterschiedliche Level, dass hier Vulkan einfach viele Kopfschmerzen vermeidet, sowohl beim Entwickler als auch beim Anwender.

[DanMan]

Du attackierst deinen selbst aufgestellten Strohmann. Ich hab nie behauptet, dass es durch Vulkan automatisch schneller sein sollte. Schneller als was überhaupt?

Meine These war und ist, dass weil die Leistung so viel schlechter ist als unter Windows, dass es sich darum wohl nur um einen Wrapper und keinen Rewrite handelt.

Doom habe ich als Vergleich gewählt, weil es - glaube ich - das einzige, native Vulkan Spiel ist, das man überhaupt auf Linux ausprobieren kann. Alle anderen sind nur D3D mit Wrapper ausgestattet SWIW.

Ich glaube auch nicht an einen Wrapper. Wenn man Source hat dann ist das eigentlich der umstaendlichste Weg.
Wenn man das von Berufswegen ständig macht, dann ist es einfacher und kosteneffizienter sich einen Wrapper zu bauen als jedes Mal bei Null anzufangen.

[gravitationsfeld]

Ich glaube auch nicht an einen Wrapper. Wenn man Source hat dann ist das eigentlich der umstaendlichste Weg.

Allein den ganzen COM-Scheiss von D3D zu implementieren ist ein riesiger Akt.

[Ganon]

Du attackierst deinen selbst aufgestellten Strohmann. Ich hab nie behauptet, dass es durch Vulkan automatisch schneller sein sollte. Schneller als was überhaupt?

Ich "attackiere" hier niemanden. Wie ich schon sagte: Meine Aussage ist, dass die Performance keine Rückschlüsse auf Wrapper/TransitionLayer/Native gibt. Es kann sich bisher auch nur um einen performancetechnisch schlechten Port handeln. Und wie schon gesagt: Ich behaupte nicht, dass es kein Wrapper ist.

[Ganon]

Ich glaube auch nicht an einen Wrapper. Wenn man Source hat dann ist das eigentlich der umstaendlichste Weg.

Feral hat wohl einen "Wrapper" bzw. Source Transition Layer "IndirectX". Also statt zur Laufzeit alles zu übersetzen wird wohl zur "Compilezeit" DX durch OpenGL ersetzt.

Wie das im Detail funktioniert, weiß ich aber nicht und inwieweit dass noch bei Vulkan zum Einsatz kommt weiß ich auch nicht. Es gibt dort auch relativ wenig Informationen zu und da mich das Spiel auch so 0 interessiert habe ich auch keine Lust mir das zu kaufen :D

[aufkrawall]

Forza Horizon 3 ohne UWP wär ganz nett. :freak:

[gravitationsfeld]

Man muss nicht "die ganze Engine umschreiben" um die API zu aendern.

[Demirug]

Allein den ganzen COM-Scheiss von D3D zu implementieren ist ein riesiger Akt.

Das ist doch nur IUnknown. Die ganzen komplizierten COM Sachen nutzt D3D doch gar nicht. Ich habe mehr als einmal ein Module programmiert das nach außen hin die D3D interfaces haben musste. Der COM Anteil war dabei jedesmal geschenkt.

Wenn man allerdings den vollständigen Sourcecode hat würde ich das auch nicht unbedingt machen. Aber nicht wegen COM sondern weil es immer Dinge gibt die sich einfach schlecht von einer API zu einer anderen mappen lassen ohne massiv Overhead zu erzeugen.

[aufkrawall]

Feral sind halt auch nicht Dice oder Ubisoft, die werden beim Aufwand wahrscheinlich ziemliche Kompromisse eingehen müssen.
Valve hatte den OGL-Port der Source Engine ja auch nur hingeschissen und für Vulkan gilt für die bisher erhältlichen Resultate von ihnen das Gleiche.

[iuno]

Phoronix hat jetzt nachgelegt. radv funktioniert demnach tatsaechlich ganz gut (bis auf Vega, wo es Artefakte gibt). Auch die Performance ist imho relativ zu Nvidia ordentlich (1060<580<V56<1070<V64<1080).
Wuerden die Publisher jetzt noch auf die Idee kommen, sowas direkt mit Vulkan OS-uebergreifend entwickeln zu lassen...

[aufkrawall]

Joa, radv ist hier ordentlich. Kein Vergleich zur mieserablen Performance in Dota 2.

[aufkrawall]

Sieht auch gegen amdgpu-pro gut aus:
https://www.phoronix.com/scan.php?page=article&item=radv-pro-f12017&num=1
Dann kann AMD jetzt so langsam mal ihren Treiber behalten und stattdessen in radv investieren. :rolleyes:

Btw. hat er mit Ubuntu 17.04 Unity getestet. Will gar nicht wissen, was das für lustige Fehler mit Nvidia-Vulkan macht...

[Gast]

Phoronix hat jetzt nachgelegt. radv funktioniert demnach tatsaechlich ganz gut (bis auf Vega, wo es Artefakte gibt). Auch die Performance ist imho relativ zu Nvidia ordentlich (1060<580<V56<1070<V64<1080).
Wuerden die Publisher jetzt noch auf die Idee kommen, sowas direkt mit Vulkan OS-uebergreifend entwickeln zu lassen...
Vega64 wird bei den phoronix Benchmarks in 1080p von einer GTX1060 zersägt, was daran "ganz gut" sein soll kann ich nicht nachvollziehen.

[iuno]

Dann kann AMD jetzt so langsam mal ihren Treiber behalten und stattdessen in radv investieren. :rolleyes:

Ist wirklich so, aber das war ja inzwischen fast abzusehen. Gut, ich glaube Feral hat auch hauptsaechlich mit radv gearbeitet. Wobei dem natuerlich auch noch Dinge fehlen, ich bin z.B. nicht sicher ob der ueberhaupt AC kann. Trotzdem ist es jetzt halt so und da ist der Plan vom gemeinsamen Windows+Linux Treiber halt schon wieder hin, weil der einfach vollkommen irrelevant ist.


Mit Intel scheint das Spiel uebrigens nicht zu laufen.

Btw. hat er mit Ubuntu 17.04 Unity getestet. Will gar nicht wissen, was das für lustige Fehler mit Nvidia-Vulkan macht...
Sowas lustiges wie 10 tear lines? :P

[aufkrawall]

Habs mal getestet: Habe auch ohne Vsync kein Tearing auf Screenshots mit Spectacle, sofern da nichts stört.
"Sofern" ist in dem Fall aber schon ein nicht sauber funktionierendes Tray-Icon von XDMan. Man muss also etwas aufpassen, aber es geht. So gesehen schon mal besser als unter Windows, wo Screenshot-Tools bei Vulkan im Vollbild sich gerne verweigern.

[=Floi=]

wieviel % kann eigentlich cpu-leistung eingespart werden? gibt es da vor allem im konsolen und mobilen bereich benchmarks oder messungen und dort die leistungssteigerung bei einer schwachen cpu zu messen?

[SaschaW]

Ja, gibt es, z.B. hier: https://www.youtube.com/watch?v=rvCD9FaTKCA

Man sieht schön dass die CPU-Auslastung geringer ist und v.a. über mehrere Kerne verteilt wird (Hauptproblem von OpenGL/ES). Dadurch spart man im mobilen Bereich einiges an Energie, das ist da wichtiger als hohe Frameraten. Interessant z.B. bei Geräten mit big.LITTLE Architektur, da kann man dann die schwachen Kerne für Dinge benutzen die weniger kritisch/aufwendig sind und die Last so schön auf die zugrunde liegende Architektur anpassen.

[blaidd]

Btw:

Wolfenstein 2 im (möglichst) heftigen CPU-Limit (https://www.youtube.com/watch?v=oKRdeltq7sY). Ist schon ganz eindrücklich.

[Raff]

Läuft wahrlich auf jedem Taschenrechner. :biggrin: Ich lasse das Spiel nachher mal auf meinem Phenom II X6 laufen und bin gespannt, was die Engine damit anstellt.

MfG,
Raff

[san,salvador]

Da fragt man sich dann aber auch warum man die zusätzlich freigewordene CPU Leistung nicht für zusätzliche Effekte, KI Gegner oder Physik genutzt hat.

[aufkrawall]

Weil Konsolen 60fps.

[gravitationsfeld]

Genau. 6,5 1.6Ghz Jaguar-Kerne sind kein Spaß. Außerdem gibt's ja auch einiges an Kaputtmachbarem in New Colossus.

[aufkrawall]

Serious Sam Fusion hat jetzt auch DX12. Läuft leider besser als Vulkan...

[][immy]

Da fragt man sich dann aber auch warum man die zusätzlich freigewordene CPU Leistung nicht für zusätzliche Effekte, KI Gegner oder Physik genutzt hat.
Gegner-KI hätte die Anforderungen erhöht und damit hätte man kunden ausgeschlossen. Abschaltbare KI ist nicht grad sinnvoll. Und wenn ein höherer Schwierigkeitsgrad nur mit besser CPU möglich ist, gäbe es garantiert den einen oder anderen Shitstorm.

zusätzliche Effekte sind meist ja nicht CPU-Orientiert und Phyisk, naja hätte man natürlich machen können, aber das Resultat rechtfertigt meist nicht den Aufwand der zusätzlich rein gesteckt werden müsste.

Serious Sam Fusion hat jetzt auch DX12. Läuft leider besser als Vulkan...
Was ist so schlimm daran? Kann natürlich daran liegen, das die Treiber aktuell noch nicht auf Vulkan hin optimiert wurden, da es da nicht all zu viele Spiele gibt die das unterstützen. Gut DX12 auch, aber hier ist die Anzahl wenigstens überschaubar.

[dargo]

Serious Sam Fusion hat jetzt auch DX12. Läuft leider besser als Vulkan...
Wieso leider?

[deekey777]

Wieso leider?
Vielleicht wegen SteamOS.

Möglicherweise wollte erschreiben, dass DX12 noch besser läuft als Vulkan.

[Locuza]

Croteam hat von Anfang an nur mit Vulkan gearbeitet und auch selber die Frage gestellt, wieso man DX12 umsetzen sollte, wenn man Vulkan hat?
Jetzt hat man am Ende doch DX12 umgesetzt und es läuft besser, wobei als Kunde man natürlich lieber eine Plattform unabhängige API vorne sehen möchte.

Woran liegt es nun? Bessere Treiber und Tools bei DX12? Oder genießt DX12 einfach eine bessere Implementierung, weil die Techniker sich bei der Entwicklung vorerst nur darauf konzentriert haben?

[aufkrawall]

Beim Vulkan-Pfad gibts z.B. immer noch ein Problem mit dem Shader-Compiler. Offenbar ist der Wechsel von HLSL -> SPIR-V mal nicht eben mit einem Fingerschnippen getan, wenn das Ganze in Echtzeit auch noch ohne Stalls laufen soll. Zudem sind im GPU-Limit DX11/12 auch (immer noch) ~15% schneller.
Witzigerweise ist DX12 auf Nvidia auf Anhieb ca. gleich schnell wie DX11 im GPU-Limit (und im CPU-Limit geringfügigst schneller). Da fragt man sich echt, was einige Entwickler rauchen, wenn sie es vollbringen, dass DX12 auch nach zig Patches immer noch massiv schlechter läuft.

DX11 läuft in Fusion trotzdem noch am besten, perfekte Frametimes und auch locker dreistellige fps im CPU-Limit. Das Spiel lastet auch nur maximal zwei Threads voll aus, egal mit welcher API.
Vulkan ist btw. im CPU-Limit trotz der anderen Probleme leicht am schnellsten. Wahrscheinlich auf Linux auch immer noch etwas schneller als auf Windows in BFE. Obs die abnormen Unterschiede pro Linux in TFE/TSE immer noch gibt, hab ich nicht wieder getestet. Dieser alte Content ist für Tests halt komplett uninteressant, wenn man auch BFE hat.

[Ganon]

Ich würde jetzt einfach mal auf bessere Optimierung innerhalb der Treiber und dem OS tippen. Ist ja eigentlich auch egal... solange dieses "Portable Vulkan" noch nicht da ist, wird eh kaum einer pures Vulkan benutzen, gerade weil Apple nicht mitmacht. Von daher muss man eh mehrere Engine-Backends haben, wenn man das Spiel auf mehrere Betriebssysteme bringen will.

Das wird im Großen und Ganzen die Nische bleiben die OpenGL zuvor besetzt hatte.

Offenbar ist der Wechsel von HLSL -> SPIR-V mal nicht eben mit einem Fingerschnippen getan, wenn das Ganze in Echtzeit auch noch ohne Stalls laufen soll.

Huh? Man kompiliert doch Shader nicht jeden Frame neu?

[aufkrawall]

Ich würde jetzt einfach mal auf bessere Optimierung innerhalb der Treiber und dem OS tippen. Ist ja eigentlich auch egal... solange dieses "Portable Vulkan" noch nicht da ist, wird eh kaum einer pures Vulkan benutzen, gerade weil Apple nicht mitmacht. Von daher muss man eh mehrere Engine-Backends haben, wenn man das Spiel auf mehrere Betriebssysteme bringen will.

Das wird im Großen und Ganzen die Nische bleiben die OpenGL zuvor besetzt hatte.

Ich denke nicht, dass man das so technisch begründen kann. Wolfenstein 2 kommt recht gut mit Vulkan-only daher.
Außerdem gibts in Fusion btw. auch mit DX12 wieder Probleme mit Crashes beim Umschalten von Vollbild zu borderless etc. Das hat offenbar Microsoft ziemlich verkackt unter Windows mit dem DWM-Schwachsinn für die neuen LL-APIs.


Huh? Man kompiliert doch Shader nicht jeden Frame neu?
Offenbar werden Shader auch @ runtime kompiliert, und da klemmts irgendwo bei Fusion + Vulkan.

[Ganon]

Wolfenstein 2 kommt recht gut mit Vulkan-only daher.

Die idTech Engines zuvor mit OpenGL auch, trotzdem bekam OpenGL nie einen sonderlichen Durchbruch. Vulkan behebt viele Probleme von OpenGL, aber hier hilft es jetzt nicht, dass man es quasi nur für Linux wirklich alternativlos braucht. Das war bei OpenGL noch anders.

Offenbar werden Shader auch @ runtime kompiliert, und da klemmts irgendwo bei Fusion + Vulkan.

Klar können Shader auch per RunTime kompiliert werden, aber das macht man hoffentlich auch nicht alle 200ms.

[vinacis_vivids]

SS-Fusion kann man nicht mit idtech vergleichen. Wer hier länger mit Vulkan gearbeitet hat, dürfte jedem Kindergartenkind klar sein.

DX11 ist nach wie vor nativ bei dieser Engine, weshalb es nicht verwundern darf, dass es da auch am besten läuft. Auf Nvidia-Karten darf man ohnehin nichts im LL-API erwarten, höchstens die Vermeidung von Verlusten.

[aufkrawall]

Es gab Vulkan in Talos Principle schon Monate vor dem OGL-only Release von Doom. Tu nicht so, als ob du wüsstest, was bei den Studios intern passiert.
Davon abgesehen läuft das mit Radeons keinen Deut besser als mit Geforces.

[vinacis_vivids]

idtech ist die Software-Referenz für Vulkan und AMD das hardwareseitige Gegenstück.

"Vulkan: The Talos Princriple in drei Monaten von einem Mann portiert, noch langsamer als DX11"
http://www.pcgameshardware.de/The-Talos-Principle-Spiel-54495/News/Vulkan-Steam-Portierung-1186472/

Ein Mann soll auf Vulkan portieren...

[aufkrawall]

Ironischerweise ist der F1 2017 Vulkan-Port im GPU-Limit ähnlich schnell wie DX11, im CPU-Limit aber wesentlich langsamer:
https://www.phoronix.com/scan.php?page=article&item=nv-radeon-win10ubuntu&num=4
Da sieht man auch wieder, wie schlecht RadV noch im Vergleich zum Vulkan-Treiber von Nvidia ist.

[gravitationsfeld]

Das muss nicht unbedingt an RADV liegen. AMD muss z.B. vertex buffer emulieren was auf Windows gut 50% des Treiber-Overheads mit Vulkan ausmacht in meinen Faellen.

Kurz, es ist nicht immer alles so einfach :)

[Ganon]

AMD wird wohl in den nächsten Tagen ihren Vulkan-Treiber auf Github ( https://github.com/GPUOpen-Drivers ) veröffentlichen:
https://www.phoronix.com/scan.php?page=article&item=amd-open-vulkan&num=1

[iuno]

Interessant wird dabei noch die Lizenz und natuerlich ob es Auswirkungen auf Mesa/radv geben wird. Falls es 3rd party contributions gibt koennte es auch problematisch werden, das fuer Windows einzupflegen. Ich bin gespannt

Nebenbei finde ich es auch schade, dass ich bis jetzt auch wieder nur auf phoronix davon erfahren habe.

[aufkrawall]

Hoffentlich landen die nötigen Änderungen für llvm nicht erst ein zig Monaten, sonst werden die Distris den Treiber nicht einfach shippen können.
Für den Enthusiasten mit 3rd Party Repo natürlich egal, aber für Spiele-Entwickler nicht. Außer, es läuft auch alles gut, was auf radv optimiert ist.

[iuno]

jedenfalls ist radv auch im aktuellen Test wenn ueberhaupt nur geringfuegig lahmer: https://www.phoronix.com/scan.php?page=article&item=amdgpu-1750-open
(abgesehen von Vega, wo radv ganz offensichtlich noch nicht problemlos laeuft)

Und dabei muss man halt bedenken, dass radv in den Distributionen dann sehr komfortabel laeuft, ohne dass man custom Kernel, llvm oder sonst was braucht. Da bleibt die Frage nach der Relevanz sicher nicht nur bei mir weiterhin bestehen. Auch Feral hatte ja jetzt auch schon mit radv zu tun und F1 laeuft aktuell schonmal nicht auf dem -pro. Ich denke nicht, dass die sich da gross fuer den interessieren werden.

Vielleicht kann sich radv was nuetzliches rauspicken, Extensions unterstuetzt der AMD Treiber ja immerhin schon mehr. Dann hat er wenigstens trotzdem noch einen Zweck erfuellt, auch ohne dass er gross eingesetzt wird.

[Ganon]

Nicht vergessen, dass das dann ja auch die Windows-Version der Vulkan-Implementierung ist. Also ganz so sinnlos ist das jetzt alles nicht ;)

[Locuza]

Interessant wird dabei noch die Lizenz und natuerlich ob es Auswirkungen auf Mesa/radv geben wird. Falls es 3rd party contributions gibt koennte es auch problematisch werden, das fuer Windows einzupflegen. Ich bin gespannt

Nebenbei finde ich es auch schade, dass ich bis jetzt auch wieder nur auf phoronix davon erfahren habe.
Für mich war der Adrenalin Launch ziemlich unspektakulär und etwas enttäuschend nachdem ich bei CB und PCGH drüber geschaut habe und just auf Phoronix gab es dann die Meldungen mit den Closed- + Open-Source Komponenten im 17.50 Pro-Treiber und der Öffnung des Vulkan-Treibers, wobei wie ich sehe Anandtech auch Informationen diesbezüglich im Artikel hatte.

Das empfinde ich als spannendste Neuheit, wenn AMD ihren Vulkan-Treiber öffnet und wie das von den Entwicklern und der beteiligten Community aufgenommen wird.

Aktuell wäre ich froh darüber, wenn der offene OpenGL-Treiber auch unter Windows eingepflegt wird und die Nutzer die Wahl haben bzw. am besten den geschlossenen vielleicht ganz entsorgen könnte, wobei AMD aufgrund der Kompatibilität das vermutlich nicht machen wird.

Bei RADV vs. AMD Vulkan würde ich eher hoffen, dass sich alle auf AMD Vulkan fokussieren, gleiche Arbeit doppelt zu machen ist nicht toll es wäre gut, wenn AMD es leichter hätte die Verbesserungen oder Code-Beiträge auch in Windows einzupflegen.

Hoffentlich landen die nötigen Änderungen für llvm nicht erst ein zig Monaten, sonst werden die Distris den Treiber nicht einfach shippen können.
Für den Enthusiasten mit 3rd Party Repo natürlich egal, aber für Spiele-Entwickler nicht. Außer, es läuft auch alles gut, was auf radv optimiert ist.
Darf man hier etwa, etwas anderes erwarten?
Bis etwas out-of-the-box simpel funktioniert und es eine stabile Entwicklung gibt, wird es sicher wieder unzählige Monate benötigen.

[aufkrawall]

llvm 6 ist halt um Februar/März angepeilt. Landet es da nicht, wär es wohl erst mit 7 in September möglich.
Es ging jetzt ja vieles recht plötzlich bei AMD, ganz würd ichs nicht abschreiben.
Die Verzögerung, bis Distris den eigentlichen Treiber in den Repos haben, wär dann wahrscheinlich nochmal zusätzlich recht fies (wenn es die Lizenz erlaubt).

[Ganon]

Aktuell wäre ich froh darüber, wenn der offene OpenGL-Treiber auch unter Windows eingepflegt wird und die Nutzer die Wahl haben bzw. am besten den geschlossenen vielleicht ganz entsorgen könnte, wobei AMD aufgrund der Kompatibilität das vermutlich nicht machen wird.

So schnell wird das nichts. Der offene Treiber unterstützt z.B. das OpenGL Kompatibilitätsprofil nicht. Das heißt so gut wie jedes größere OpenGL >= 3 Spiel und Anwendung würde mit den Open Source Treibern nicht laufen.

Die Arbeiten daran sollen wohl nächstes Jahr beginnen, wenn OpenGL 4.6 fertig implementiert ist. Wie lange es dann dauert... tjoahr...

[gmb]

Vulkan auf Intel IGP unter Windows kann man eigentlich komplett vergessen. Der Treiber ist seit ewig beta und hinkt dem ziemlich guten Linux Intel IGP-Treiber komplett hinterher. Was Vulkan unter Windows angeht ist Intel eine totale Enttäuschung.


Schau dir mal den neuen 15.60.1.4877 (https://downloadmirror.intel.com/27355/eng/ReleaseNotes_GFX_15.60.01.4877.pdf) an. Meine ganzen Vulkan Spiele laufen damit (Doom, Wolfenstein Colossus, Serious Sam). Hat sich massiv verbessert.

[gravitationsfeld]

Hier ein Video:
https://www.youtube.com/watch?v=sBOwUB4tHWA

Bin relativ beeindruckt

[Loeschzwerg]

Schau dir mal den neuen 15.60.1.4877 (https://downloadmirror.intel.com/27355/eng/ReleaseNotes_GFX_15.60.01.4877.pdf) an. Meine ganzen Vulkan Spiele laufen damit (Doom, Wolfenstein Colossus, Serious Sam). Hat sich massiv verbessert.

Doom @ Vulkan flutscht mit dem Treiber richtig gut, auch wenn OGL immer noch minimal bessere FPS liefert :) Werde mir jetzt mal die Wolfenstein II Demo saugen und mit der Iris Pro testen.

[Kartenlehrling]

A new steam client has been released and is being automatically downloaded.

Update: this client was released again on Dec 15 with additional fixes for newly reported issues.

General

New feature:
Shader Pre-Caching. Whenever possible, depending on hardware and driver support,
Steam can download pre-compiled shaders for your specific video card.
This reduces load times and in-game stuttering during the first few launches of OpenGL- and Vulkan-based games on supported hardware.
This feature may use a small amount of additional bandwidth as Steam uploads and analyzes a shader usage report after each run of the game.
The feature can be disabled via a new entry in the Settings dialog.
http://store.steampowered.com/news/35534/

[Loeschzwerg]

Wolfenstein II mit der Iris Pro 580:
https://www.youtube.com/watch?v=Y-WUEOEblFk

[x-force]

eine 530 läuft laut anderen videos von haus aus auf 720p und low schlechter. wie schön wäre es wenn intel nochmal einen versuch im dgpu markt startet: 256bit gddr5x interface in verbindung mit min 288 eus :D

[robbitop]

GT4e - eDRAM und eine extra breite GPU die in fast keinem Produkt vorkommt. Und ein Spiel was totoptimiert wie kein zweites ist ist. Man schafft ~40 fps in 720p... wow

[Loeschzwerg]

1366x768 + Hohe Details bitteschön ^^

@x-force: Abwarten was sich in 3-4 Jahren aus dem neuen Projekt unter der Führung von Raja entwickelt. Ob überhaupt für Consumer ist auch noch die Frage... aber schön fände ich es zumindest.

[gmb]

Wolfenstein II mit der Iris Pro 580:
https://www.youtube.com/watch?v=Y-WUEOEblFk


Das müsste deutlich über einer GTX 950M (https://www.notebookcheck.com/Wolfenstein-II-The-New-Colossus-Notebook-und-Desktop-Benchmarks.261034.0.html) einzuordnen sein, die schafft nämlich nur 52 fps in 720p low. Auf jeden Fall scheint Intels neuer Vulkan Treiber das GPU Potenzial komplett oder fast komplett abrufen zu können.

[Loeschzwerg]

Es hat sich wirklich ordentlich was getan, aber einen Vergleich zur 950M würde ich nicht direkt ziehen, immerhin habe ich eine komplett andere Szene gespielt als Notebookcheck.

Ich werde mir das Spiel aber eh noch kaufen und dann schaue ich mir das nochmals an.

[Iruwen]

Abwarten was sich in 3-4 Jahren aus dem neuen Projekt unter der Führung von Raja entwickelt.

Noch ein Papiertiger?

[Loeschzwerg]

Schau mer mal :D Zumindest braucht dann keiner behaupten es sei am fehlenden R&D Budget gescheitert ^^

[Pirx]

Wird wahrscheinlich gut werden, leider (im Sinne des Wettbewerbs), Raja ist nicht irgendwer.

[TheAntitheist]

Wird wahrscheinlich gut werden, leider (im Sinne des Wettbewerbs), Raja ist nicht irgendwer.
eigentlich hat er nur viel geschwafelt und null abgeliefert...

[Hübie]

Also A) ist das keine in-Mann-Show, B) zolle ich jedem der so etwas entwickelt und versteht mehr Respekt und C) liegt da noch zu viel im Nebel, als dass man es thematisieren könnte.

@Loeschzwerg: Die HD580 war jetzt Skylake mit 64 MB eDRAM? Hab's bei Intel nicht so mit den Namen.

[Loeschzwerg]

128MB eDRAM. 64MB haben z.B. die Iris 540 bzw. Iris 550.

[Hübie]

Hö? Ich dachte bisher es gäbe seit Skylake nur noch max 64 MB, weil man ja bei Broadwell 'zu schnell' war. X-D iirc ist der 5770c immer noch der schnellste Quadcore+HT, aber wird in den wenigsten Tests verwendet. Das nur am Rande. :D

Also ist deine iGPU besser als die HD630, richtig? Sorry für die dummen Fragen. :D

[Loeschzwerg]

Nope, es sind 128MB und ja, die 580 ist meilenweit besser :)

Die HD 6xx basieren wie die HD 5xx ebenfalls auf Gen9. Bedingt durch die etwas bessere Fertigung von KBL/CFL kann die HD 6xx Serie im Power-Budget etwas höher takten.

[Hübie]

Alles klar. :up: Schon beeindruckende Performance für so einen kleinen Chip.

[Kartenlehrling]

Um Vulkan in Sling Shot Extreme nutzen zu können, wird Android 7.0 Nougat (Test) vorausgesetzt,
für OpenGL ES 3.1 muss es mindestens Android 5.0 Lollipop sein.
https://www.computerbase.de/2017-12/3dmark-android-vulkan/


Auf meinen Samsung s6edge (Android 7.0) macht der Vulkan Grafik Farbfehler/Streifen, die Werte sind schlechter als OpenGL es3.1,
1424 (692 Energie-sparmode) OpenGL, Vulkan 1112 (547 Energie-sparmode) (Grafikfehler) , bei 3-5fps (Extreme Mode) kann man auch schwer von flüssig reden.

hatte bei der ersten Messung vergessen den Energie Sparmode auszuschalten,
an den Farb/Streifen Fehler hat das aber keine Auswirkung.

[gmb]

Hö? Ich dachte bisher es gäbe seit Skylake nur noch max 64 MB, weil man ja bei Broadwell 'zu schnell' war. X-D iirc ist der 5770c immer noch der schnellste Quadcore+HT, aber wird in den wenigsten Tests verwendet. Das nur am Rande. :D



Der schnellste Quadcore mit HT ist der i7-7700k, speziell in Verbindung mit schnellem DDR4. Dem Broadwell fehlt es an Taktfrequenz, bei spätestens 4.2 GHz mit OC ist Feierabend, und DDR4 Support.

[Nightspider]

Naja 5775C @ 4,2 und 7700Ghz @ 5Ghz werden sich vermutlich nicht viel nehmen in Spielen.

In manchen Games würde vielleicht der 5665C vorne liegen und in den meisten Games der 7700K.

Einen Test mit 7700K und 4000er RAM vs. 5775C gabs halt leider nie.

[gmb]

Es hat von schnellstem Quadcore gesprochen, das betrifft somit genauso Anwendungen. Auch müsste er vorne liegen und nicht nur "nicht viel nehmen". Der edram wird von schnellem DDR4 negiert in Spielen. Da wo ich 10-20% durch schnellen DDR4 gewinne, wird sicher auch der edram viel bringen. Aber nicht so viel, als dass er IPC und Taktnachteil nicht nur ausgleichen kann, sondern sogar vorbeiziehen kann. Selbst wenn das in einem von 10 Spielen so sein sollte, keine Chance.

[Hübie]

Ich denke wenn beide auf 4.3-4.5 GHz laufen, dann kennen wir den Gewinner. ;) Der ist echt heftig, unterschätz das mal nicht, gmb.

[gravitationsfeld]

Also A) ist das keine in-Mann-Show, B) zolle ich jedem der so etwas entwickelt und versteht mehr Respekt und C) liegt da noch zu viel im Nebel, als dass man es thematisieren könnte.

@Loeschzwerg: Die HD580 war jetzt Skylake mit 64 MB eDRAM? Hab's bei Intel nicht so mit den Namen.
Raja war im Management zuletzt. Weiss nicht wieviel Hands on da noch war.

[Gast]

8C 4,5Ghz + fetten Cache is the way to Go. Mal schauen wer den zuerst bringt, das frisst viel Fläche.

[Hübie]

Raja war im Management zuletzt. Weiss nicht wieviel Hands on da noch war.

Guter Punkt. Wenn ich mich nicht täusche kam er auch in einer relativ späten Phase ins Team und konnte entsprechend gar nicht mehr so gravierende Entscheidungen treffen um das Ruder herum zu reißen. Ich fand seine Auftritte zwar immer peinlich genug um sich fremd zu schämen, aber er hat seine Patente; was ihn schon mal mehr qualifiziert als 99,99% der Kritiker hier. :D Bei AMD, speziell RTG, stelle ich es mir aber schon so vor dass man im Management noch mit anpackt.

[Ganon]

Der Open Source AMD Treiber kleckert jetzt so langsam in die Repos.

https://github.com/GPUOpen-Drivers

Zumindest ihr Platform Abstraction Layer ist bereits Online und vom Vulkan Treiber der ICD.

[iuno]

Finde die Architektur auf den ersten Blick etwas komisch, aber wenigstens scheint es alles schoen beschrieben. Ich schaue mir das spaeter mal genauer an

[aufkrawall]

MIT und nur weitere LLVM-Anpassungen upstream benötigt. =)

[gravitationsfeld]

Finde die Architektur auf den ersten Blick etwas komisch, aber wenigstens scheint es alles schoen beschrieben. Ich schaue mir das spaeter mal genauer an
Was genau findest du komisch?

[aufkrawall]

In Zukunft soll auch der Windows-Treiber auf LLVM setzen:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/996860-amd-open-source-driver-for-vulkan-amdvlk-is-now-available/page7

[gravitationsfeld]

Wird auch Zeit, ich hab jahrelang gemotzt.

[iuno]

Was genau findest du komisch?
amdvlk ist nur ein meta-repo, im Zusammenhang mit Ganons Kommentar hat mich das wohl kurz verwirrt ;p

Dass es eine Abstraktionsschicht gibt war ja abzusehen bzw. auch angekuendigt, daher wird das ja so auch nie in Mesa landen. Bin mal gespannt wie es sich jetzt weiter entwickelt und wann das komplett mit upstream Zeug (insbesondere llvm) benutzbar ist. Irgendwer koennte ja sogar auf die Idee kommen, ueber PAL weitere APIs zu implementieren. Ob sich da aber - nur fuer AMD - Freiwillige finden, ist erstmal fraglich.
Laut dem ersten Vergleich auf phoronix hat radv uebrigens sogar Vorteile auf CPU Seite (niedrigere Aufloesung)... Dafuer hat man natuerlich mehr extensions und mehr Leistung im GPU Limit. Schoen ist ja, dass man beides parallel installiert haben und je nach Anwendung waehlen kann - zumindest zum Testen, langfristig waere eine solche Notwendigkeit natuerlich weniger schoen.

Hat jemand eigentlich Ahnung, warum AMD google's repo benutzt? Bei einem Android device Tree mit 20 repos verstehe ich das ja vielleicht noch, aber bei einem Repo mit 3 submodules?

@gravitationsfeld:
Kannst du eigentlich was zu den Auswirkungen sagen? Wuerde es etwa bei euch fuer zukuenftige Releases eine Rolle spielen, wenn amdvlk bei allen gaengigen distris und damit der offizielle Vulkantreiber des Herstellers ootb mit dabei waere oder wird das mangels Marktanteil ueberhaupt nicht diskutiert?

[gravitationsfeld]

Dass es eine Abstraktionsschicht gibt war ja abzusehen bzw. auch angekuendigt, daher wird das ja so auch nie in Mesa landen. Bin mal gespannt wie es sich jetzt weiter entwickelt und wann das komplett mit upstream Zeug (insbesondere llvm) benutzbar ist. Irgendwer koennte ja sogar auf die Idee kommen, ueber PAL weitere APIs zu implementieren. Ob sich da aber - nur fuer AMD - Freiwillige finden, ist erstmal fraglich.
PAL wird auf Windows auch fuer DX12 und Mantle benutzt. Der xgl-Teil ist wohl wirklich fast gleich auf Linux und Windows.

Laut dem ersten Vergleich auf phoronix hat radv uebrigens sogar Vorteile auf CPU Seite (niedrigere Aufloesung)... Dafuer hat man natuerlich mehr extensions und mehr Leistung im GPU Limit. Schoen ist ja, dass man beides parallel installiert haben und je nach Anwendung waehlen kann - zumindest zum Testen, langfristig waere eine solche Notwendigkeit natuerlich weniger schoen.
Ich bin mir auch nicht so sicher, ob die PAL-Strategie so gut ist. Abstraktionsschichten verursachen immer mehr Overhead.

@gravitationsfeld:
Kannst du eigentlich was zu den Auswirkungen sagen? Wuerde es etwa bei euch fuer zukuenftige Releases eine Rolle spielen, wenn amdvlk bei allen gaengigen distris und damit der offizielle Vulkantreiber des Herstellers ootb mit dabei waere oder wird das mangels Marktanteil ueberhaupt nicht diskutiert?
Verstehe die Frage nicht. Auswirkungen auf was? Das wir was veroeffentlichen fuer Linux?

[iuno]

PAL wird auf Windows auch fuer DX12 und Mantle benutzt. Der xgl-Teil ist wohl wirklich fast gleich auf Linux und Windows.
Ja, das ist mir schon klar. Ich meinte, dass es ja theoretisch denkbar waere, dass eine community etwa d3d12 darueber implementiert, als ueber Vulkan zu gehen, wie das WINE beispielsweise gerade macht.

Verstehe die Frage nicht. Auswirkungen auf was? Das wir was veroeffentlichen fuer Linux?
Genau. Z.B. ging es ja bei Ferals Ports immer hin und her wo ein Spiel ueberhapt laeuft und wo es "unterstuetzt" wird. Wenn es drei verschiedene HW Hersteller und dazu sechs verschiedene stacks gibt von denen nur die Haelfte offiziell ist oder nirgends laeuft schreckt das vermutlich schon ab. Ich denke, dass es einen Unterschied machen kann, ob der offizielle Treiber ootb auf den wichtigen Distributionen einfach laeuft?

[danarcho]

Dass es eine Abstraktionsschicht gibt war ja abzusehen bzw. auch angekuendigt, daher wird das ja so auch nie in Mesa landen. Bin mal gespannt wie es sich jetzt weiter entwickelt und wann das komplett mit upstream Zeug (insbesondere llvm) benutzbar ist. Irgendwer koennte ja sogar auf die Idee kommen, ueber PAL weitere APIs zu implementieren. Ob sich da aber - nur fuer AMD - Freiwillige finden, ist erstmal fraglich.
Ich sehe nicht, wieso PAL ein Argument gegen Mesa sein sollte. Aber gedulde dich ein bisschen, der Treiber ist ja grad eine Woche raus. Ich sag Bescheid, wenn ich mehr weiß.
Die Idee, mithilfe von PAL auch DX12 zu unterstützen, finde ich ganz reizvoll. Wäre mal interessant, ob AMD das herausgeben darf oder ob man es nachbauen müsste.

@gravitationsfeld:
Kannst du eigentlich was zu den Auswirkungen sagen? Wuerde es etwa bei euch fuer zukuenftige Releases eine Rolle spielen, wenn amdvlk bei allen gaengigen distris und damit der offizielle Vulkantreiber des Herstellers ootb mit dabei waere oder wird das mangels Marktanteil ueberhaupt nicht diskutiert?
Mich würde ja mehr die Rage Engine interessieren, aber ich denke nicht, dass wir hier viele Infos dazu bekommen (dürfen). :massa:

[iuno]

AMD hat doch gar kein Interesse, das in Mesa zu bringen. Und wieso sollten es die Leute von dort aufnehmen? Die haben schon einen Vulkan Treiber und vermutlich keinen Bock auf ein weiteres AL neben gallium.
Dave hat uebrigens schon damit angefangen, was in radv zu ziehen (1 (https://lists.freedesktop.org/archives/mesa-dev/2017-December/180704.html), 2 (https://lists.freedesktop.org/archives/mesa-dev/2017-December/180705.html), 3 (https://lists.freedesktop.org/archives/mesa-dev/2017-December/180706.html))

[aufkrawall]

Etwas enttäuschend jedenfalls, dass man nicht auf Anhieb die Windows-Performance hat. Nvidia ist bei den Linux-Spielen mit Vulkan in ausnahmslos jedem Fall schneller als mit OGL. Hab aber noch Hoffnung für amdvlk.

[danarcho]

AMD hat doch gar kein Interesse, das in Mesa zu bringen. Und wieso sollten es die Leute von dort aufnehmen? Die haben schon einen Vulkan Treiber und vermutlich keinen Bock auf ein weiteres AL neben gallium.
Wieso denkst du, dass AMD kein Bock hat? AMDVLK ist abgeleitet vom Windows-Treiber. Dass da noch nichts zu mesa passt, ist doch klar. Wer ist denn "die Leute"? Bas und Dave? Natürlich gibt es ein starkes Interesse daran, gemeinsam zu arbeiten.
Was die Performance angeht: AMDVLK benutzt einen ziemlich primitiven Shader-Compiler, der praktisch nur den SPIRV->LLVM Translator von Khronos mit dem LLVM backend verbindet. An der Stelle ist radv etwas weiter.

AMD möchte mittelfristig auch unter Windows auf LLVM setzen, wovon dann auch die Linux-Treiber profitieren werden. Vielleicht ist der Nvidia-Treiber für Vulkan unter Linux noch stärker, aber schau dir einfach mal an, wie sich der OpenGL Treiber von AMD entwickelt hat. Ich denke, wir können für die Zukunft viel erwarten.

[gravitationsfeld]

Inwiefern ist RADV beim Shader-Compiler weiter? Benutzt doch auch LLVM, wenn auch zuerst durch NIR. Ich bin mir nicht so sicher, ob das ein Vorteil ist. Ich wuerde LLVM auch nicht als "primitiv" bezeichnen :)

[danarcho]

Hab mich vielleicht nicht so präzise ausgedrückt. Mit primitiv meinte ich nicht das LLVM backend, sondern die LLVM codegen. Da RADV NIR benutzt, kann es auch von den optimization passes profitieren, während AMDVLK "lediglich" die optimizations aus LLVM zur Verfügung stehen. Der Unterschied ist jetzt nicht besonders groß (immerhin gibt es einen!), gibt aber etwas mehr Möglichkeiten. Das einzige was mich an NIR nervt, ist, dass es typeless ist, und RADV daher voller Bitcasts. So oder so: ich denke nicht, dass beide Treiber lange nebenher existieren werden.

[gravitationsfeld]

RADV sagt NIR koennte theoretisch Inter-Stage-Optimierungen machen (z.B. Interpolatoren entfernen die von vertex geschrieben, aber nicht von fragment gelesen werden). Aber zur Zeit passiert das nicht.

Ansonsten sehe ich nicht was NIR optimieren soll, was LLVM nicht besser machen koennte.

[aufkrawall]

Mit AMD-GPUs macht Vulkan sogar für Video-Rendering (nicht zu verwechseln mit Encoding) Sinn.
Mit mpv-git hab ich hier mit meinen Einstellungen und dem Testvideo auf der RX 560 & Windows
D3D11: ~83fps
Vulkan: ~93fps
+~12%

Async Compute kann ja nach Einstellung auch nochmal bis zu ~7% bringen, allerdings braucht man dafür wohl Einstellungen mit sowohl genug Graphics- als auch Compute-Last.
Mit Copyback-Decoding ist Vulkan sogar ~30% schneller, aber AMD DX11 ist hier auch lahm im Vergleich zu Nvidia.

Das crappy AMD-Powermanagement braucht mit der RX 560 btw. sowohl unter Windows als auch Linux manuell erzwungenen Volltakt gegen Ekel-Ruckeln, etwas unschön...

[Troyan]

Rise of the Tomb Raider bekommt für die Linux-Portierung Vulkan: https://twitter.com/feralgames/status/963372094775013382

[AintCoolName]

Schon seltsam, was nimmt man den dann für den MAC? OpenGL oder Metal?
Ich wundere die machen das Game für DX11, DX12, Vulkan und noch was. Bei anderen heißt es alles viel zu aufwendig und zu teuer.