Vulkan Grafik-API [Archiv] - Seite 12

Ganon

2018-02-27, 08:40:42

Reicht im Großteil auch schon. Ich mach mir auch nichts vor. Vulkan wird im AAA PC-Bereich voraussichtlich keine Rolle spielen und wird weiterhin die zweite Geige für Porter sein. Und diese Porter haben bereits ihre DX11/DX12 -> Vulkan/Metal Wrapper. Und große Engines wie die Unreal Engine haben ebenfalls bereits ein Metal Backend.

Es hilft aber Indie-Studios und auch Cross-Platform (Open-Source) Projekten von Apples grottiger OpenGL Implementierung weg zu kommen ohne 2 oder 3 APIs zu pflegen. Auch hinsichtlich Mobile, denn auf iOS sieht es ja auch nicht viel besser aus. Altes OpenGL ES 3.0 und sonst nur Metal.

Rooter

2018-02-27, 10:43:41

Ich bin davon jetzt nicht so grossartig begeistert. Vulkan laesst sich nicht gescheit auf Metal implementieren, das Speicher-Modell ist einfach nicht kompatibel.

Dota 2 und so einfachere Sachen werden funktionieren.Dota 2 läuft immerhin 50% schneller:
https://www.computerbase.de/2018-02/moltenvk-vulkan-macos-ios-dota-2/

MfG
Rooter

iuno

2018-02-27, 12:31:04

Das liegt aber wohl eher daran, dass die OpenGL Treiber bei Apple schon lange stehengeblieben sind. Bei Linux gab/gibt es so einen dicken speedup iirc nicht.

Ganon

2018-02-27, 12:43:07

Ja, darum ist MoltenVK halt wichtig. Es gibt neben Metal keine Möglichkeit unter macOS schnelle und aktuelle 3D Grafik zu bekommen. Und nicht jeder Entwickler kann es sich großartig leisten mehrere APIs zu pflegen und ist dann immer auf ein altes OpenGL festgenagelt. Jetzt kann man wenigstens auf ein Vulkan Subset wechseln und erreicht damit auch noch Android und iOS, da diese vorher nur OpenGL ES konnten. Und OpenGL ES kriegt man soweit ich weiß unter macOS auch nicht zum Laufen.

aufkrawall

2018-02-27, 12:54:22

Das schließt sicherlich die Lücke für Projekte wie mpv, Emulatoren oder auch anspruchslose Mobile-Games. Also gar nicht mal so unnütz in der Breite.
AAA für Mac spielt eh keine Rolle, von daher nicht schlimm.

Troyan

2018-03-07, 15:32:50

Erstes große Vulkan Update wurde veröffentlicht: https://www.khronos.org/news/press/khronos-group-releases-vulkan-1-1

aufkrawall

2018-03-08, 19:09:19

AMD-Nutzer haben schon die Auswahl zwischen vier Treibern. :freak:

=Floi=

2018-03-08, 19:20:24

1.1 endlich mit DRM! TOP!

kruemelmonster

2018-03-09, 14:19:51

Richtig top, weil DRM-Unterstützung einer der notwendigen Bausteine für eine Ablösung von WebGL ist.

gravitationsfeld

2018-03-20, 19:03:20

Khronos arbeitet an Raytracing fuer Vulkan:
https://twitter.com/thekhronosgroup/status/976071695374213121

Hübie

2018-03-20, 20:07:54

Tolle Neuigkeiten. Nachdem es ja schon erste Titel wie Fortnite für cross-platform gibt: Welche API wird hier verwendet und welche Tendenzen gibt es in der Industrie? Gibt es da wissenwerte write ups die man sich reinziehen kann?

Ganon

2018-03-20, 20:16:03

Da es die Unreal Engine 4 ist, vermute ich hier schlicht, dass was auf die Plattform passt. D.h. Metal unter iOS, OpenGL ES unter Android, usw.

Weiß gerade gar nicht wie gut/weit die Unreal Engine 4 bei der Adaption von DX12 und Vulkan ist.

Digidi

2018-03-24, 09:16:46

Hier sind die Patente zu Primitive Shaders
http://www.freepatentsonline.com/20180082399.pdf
http://www.freepatentsonline.com/20180082470.pdf
source:
https://forum.beyond3d.com/threads/amd-vega-10-vega-11-vega-12-and-vega-20-rumors-and-discussion.59649/page-258

lässt sich davon irgendwas in Vulkan leicht einbinden?

pixeljetstream

2018-03-24, 09:28:56

Alle die die Frage beantworten können, dürfen sich den Inhalt nicht anschauen.

Allein auf das Marketing Material bezogen gibt es keinen Grund warum es nicht möglich wäre.
"Leicht" ist relativ, die Arbeit neue shader zu definieren, Compiler Support etc. ist nicht unwesentlich. Das müsste AMD erstmal alles selbst leisten bei vendor extension. Das ist sicher mehr Aufwand als die intrinsics.

pixeljetstream

2018-03-24, 09:39:58

https://twitter.com/erkaman2/status/977221617427369984?s=19

dildo4u

2018-03-24, 09:59:31

Wow Nvidia DX11 MT ist besser als AMD Vulkan.

Digidi

2018-03-24, 10:01:20

Alle die die Frage beantworten können, dürfen sich den Inhalt nicht anschauen.

Das ist doch ein offenes Patent?

Locuza

2018-03-24, 10:08:36

Wow Nvidia DX11 MT ist besser als AMD Vulkan.
WoW AMD DX11 MT ist besser als AMD Vulkan. :rolleyes:

Die Videos von der Khronos Group sind online:
https://www.youtube.com/user/khronosgroup/videos

dargo

2018-03-24, 10:14:29

Typisch dildo. ;D

btw.
Wurde Roblox echt jetzt erst auf Vulkan portiert? Laut dem hier ist dies bereits vor einem Jahr geschehen. :confused:
http://roblox.wikia.com/wiki/Graphics_settings

Oder gehts hier einfach nur um weitere Vulkanoptimierungen in Roblox?

SaschaW

2018-03-24, 10:16:44

Wow Nvidia DX11 MT ist besser als AMD Vulkan.

Bitte die Texte über den Zahlen beachten. Da steht single core.

pixeljetstream

2018-03-24, 12:00:48

Das ist doch ein offenes Patent?
Du meinst weil die website ein "free" enthält, der Zugang dass Du es lesen kannst ist frei. Patente kosten ordentlich Geld (Gebühren für einzelne Regionen, Anwaltskosten etc.), so dass ich nicht glaube dass irgendwer das zum Spaß macht.

Locuza

2018-03-24, 16:26:39

Whop Whop!

Auf einem Khronos Panel gab es eine Präsentation bezüglich Herausforderungen bei der Entwicklung und Erfahrungswerte auf Basis der Vulkan-Portierung von FF15!

Die mobile pocket Version natürlich :ucatch:
https://youtu.be/Aeo62YzofGc?t=29m17s

Digidi

2018-03-24, 16:37:58

Du meinst weil die website ein "free" enthält, der Zugang dass Du es lesen kannst ist frei. Patente kosten ordentlich Geld (Gebühren für einzelne Regionen, Anwaltskosten etc.), so dass ich nicht glaube dass irgendwer das zum Spaß macht.

Man darf nicht über ein Patent diskutieren was offen ausliegt? Man darf es nicht zur Herstellung von Produkten verwenden aber man darf doch noch darüber diskutieren?

pixeljetstream

2018-03-24, 17:55:18

Das Problem ist dass wenn man selbst in dem Bereich tätig ist, man nicht durch fremd IP "kontaminiert" werden will in seinen eigenen Lösungen. Deswegen schauen sich Entwickler niemals nach Patenten um, und deswegen ist es nicht der Sache dienlich die hier öffentlich zu diskutieren. Abgesehen davon beschreibt das Patent ja nicht zwangsläufig was man wirklich gemacht hat. Es gibt Firmen die nur Patente produzieren und nix davon wirklich umsetzen.

Ich bin mir auch nicht ganz sicher was Du Dir davon erwartest. Das Marketingmaterial zu Vega reicht imo aus um Einschätzen zu können worauf sie mit den shadern hinaus wollten und das klang ja plausibel. Warum sie die shader nicht gebracht haben bis jetzt wissen nur sie selbst, das kann kein Externer bewerten.
Das beste ist vielleicht Du kontaktierst die Leute die den AMD open-source Treiber machen ob die mehr über das Feature wissen.

Digidi

2018-03-25, 20:18:21

Was ist den das für eine Auffassung? Natürlich schaut man sich das an was die Konkurrenz macht. Meistens fällt einem dabei auf das noch eine andere Möglichkeit gibt die weniger negative Eigenschaften hat als das Konkurrenz Patent.

iuno

2018-04-02, 16:56:01

Nvidia hat jetzt auch bestaetigt, dass RTX ueber eigene Vulkan Erweiterungen verfuegbar sein wird: https://devblogs.nvidia.com/nvidia-optix-ray-tracing-powered-rtx/

https://devblogs.nvidia.com/wp-content/uploads/2018/03/Fig3_NVIDIA_raytracing_hierarchy-625x338.png

Kartenlehrling

2018-04-02, 20:46:23

The desktop Vulkan implementation supports everything the D3D11/12 path does.
On AMD we are faster than D3D11, once the slides from my GDC talk are out you can see the numbers.
https://forums.unrealengine.com/development-discussion/rendering/85035-vulkan-status?p=1452303#post1452303

Es fällt mir nicht schwer dieses zu glauben, Unreal dx11 ist immer noch stark Singlecore lasting, amd mag diese bremse überhaupt nicht.
Slider von der GDC oder benchmarks sind schön und gut, aber ein kaufbars AAA+ Spiel wär mir lieber.

Radeonfreak

2018-04-02, 20:50:59

t, aber ein kaufbars AAA+ Spiel wär mir lieber.

Unreal 3. :(

Hübie

2018-04-02, 22:46:18

https://forums.unrealengine.com/development-discussion/rendering/85035-vulkan-status?p=1452303#post1452303

Es fällt mir nicht schwer dieses zu glauben, Unreal dx11 ist immer noch stark Singlecore lasting, amd mag diese bremse überhaupt nicht.
Slider von der GDC oder benchmarks sind schön und gut, aber ein kaufbars AAA+ Spiel wär mir lieber.

Er schreibt das sie auf AMD schneller als D3D11 sind. Damit ist Vulkan@AMD>D3D11@AMD und irgendwie impliziert dies dass es auf NV wohl nicht der Fall ist.
@Complicated: Falsch. Nicht Implikation, sondern deine (Fehl-)Interpretation. Nicht umsonst schrieb ich "Missverständnis". Du ziehst die falschen schlüsse - vielleicht weil du es so möchtest. Aber EOD, da OT. :D

pixeljetstream

2018-04-02, 23:59:49

Imo ist nicht das raytracing hier der "star"/"next big thing", sondern die DL Filter, denen egal ist woher das Bild kommt ;)
Da Games meist viel breitere Basis brauchen, Mal sehen, aber im Profi Bereich sieht man ja starkes Interesse auch bei der GTC von diversen Film Firmen. Hier sind aber auch schon viele Lösungen im Einsatz die Echthzeit und Final Frame näher bringen, wird nun halt noch besser klappen und vielleicht auch ein paar custom Lösungen vereinfachen.
Bin aber biased weil eher aus dem Rasterizer Lager und sehe da nachwievor viel Potential. Wir haben aber jetzt eh schon viele Hybridansätze und mit DXR/Vk gibt's halt paar mehr. Aber im Prinzip gab's ähnliches im non gaming mit Optix oder Fire/RadeonRays halt schon ne Weile, die Filter hauen jetzt halt Mal eben ordentlich was drauf.
Grundsätzlich finde ich eh interessant das mit VR und Raytracing der Profi-Sektor erstmals wieder gegenüber Consumer im Einsatz neuer Mittel voranschreitet.
Epic hat schon ein Engagement und Unity baut sein non-gaming sicher auch aus.

Hübie

2018-04-03, 00:14:10

Das war auch im Zusammenhang mit der konkreten Lösung über Filter gemeint, da man jetzt ohne umständliche Tricks komplexere Lichtszenen darstellen kann, ohne die Performance in den Keller sacken zu lassen. Ich denke, das ist ein Schritt in die richtige Richtung. Es verkürzt ja auch die Erstellung von Inhalten, wenn ich's richtig verstanden habe. Zahlen dazu würden mich mal brennend interessieren, aber ich schätze dass man an so etwas nicht heran kommt.

Ganon

2018-04-03, 11:01:38

Bitte beim Thema bleiben. Klärt euren persönlichen Kram per PM. Entsprechende Beiträge entfernt

Locuza

2018-04-21, 08:58:06

Hübie

2018-04-21, 09:30:06

SaschaW

2018-04-21, 09:33:34

OIT würde mich grundsätzlich freuen, da dies seit Jahren ein echt störender Faktor in Spielen ist. Würde mich nicht wundern, wenn es selbst in Far Cry 5 so etwas hin und wieder noch auftreten würde. :D

OIT lässt sich auch ohne ROVs implementieren. In Vulkan ganz schick mit sub passes, nur halt leider nicht so performant. GL hat ja schon shader interlock im FS, evtl. reicht es (für den Anfang) wenn man den Kram nach VK portet (eigene Ext mit evtl. etwas erweiterten Grundanforderungen).

pixeljetstream

2018-04-21, 11:29:15

Es gibt viele oit Verfahren. Für die ganzen gbuffer basierten Rendereffekte bleiben sie aber nachwievor problematisch, deswegen sieht man sowas meist nur eingeschränkt.

http://on-demand.gputechconf.com/gtc/2014/presentations/S4385-order-independent-transparency-opengl.pdf

Loeschzwerg

2018-04-21, 12:43:47

Für Intel Gen9 gibt es im MS Update Catalog den v5018 Treiber:
https://www.catalog.update.microsoft.com/Search.aspx?q=23.20.16.5018

Der bringt den Vulkan Treiber auf Version 1.1.70. Doom läuft damit richtig gut :) Die reinen FPS sind zwar etwas langsam als unter OpenGL (ca. 3FPS), aber die Texturen werden z.B. schneller geladen und es läuft gefühlt fluffiger.

AotS Escalation macht unter Vulkan Probleme, da wird die hälfte des Menüs nicht angezeigt.

aufkrawall

2018-04-21, 13:02:11

Dass die fps niedriger als mit OGL sind, ist bei den ganzen LL-Features in der Hardware eigentlich ziemlich enttäuschend. Selbst ohne AC bringt Vulkan bei dem Spiel auf der RX 560 ~20-30% mehr fps im GPU-Limit.

Locuza

2018-04-21, 14:16:30

Kommt darauf an was du als LL-Features definierst und ansiehst.
Und die Treiber könnten möglicherweise noch Liebe vertragen, Intel kocht schon wieder eine getrennte Suppen für Windows und Linux, mit unterschiedlichen OGL- und Vulkan-Treibern von unterschiedlichen Treiber-Teams.
Anfangs gab es nicht einmal Vulkan-Treiber für Windows.

Loeschzwerg

2018-04-21, 14:25:39

Da liegt sicher noch ordentlich Potential brach, aber es geht voran (wenn auch langsam).

Locuza

2018-04-21, 14:43:59

Einfach mal als Einwurf, weil ich mich daran erinnere das gravitationsfeld bei DX12 das Resource-Binding-Tier 3 unter Maxwell/Pascal in Frage gestellt hat, was offensichtlich die Hardware-Limits überschritten hat.
Die gerade neusten Vulkan-Treiber von Nvidia gehen auch über die Hardware-Limits und Nvidia fasst es so zusammen:
https://abload.de/img/nvagrm0.jpg

Die Ursprungsquelle:
https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/26

aufkrawall

2018-04-21, 14:46:32

Kommt darauf an was du als LL-Features definierst und ansiehst.

Wenn man schon (lange) FL12_1 hat, sollte auch irgendwo die Performance bei dieser oder ähnlicher API stimmen. Die besagten 3fps sind für Intel-Verhältnisse sicherlich auch prozentual eine echt hässliche Einbuße, auch verglichen mit Nvidia.

Und die Treiber könnten möglicherweise noch Liebe vertragen, Intel kocht schon wieder eine getrennte Suppen für Windows und Linux, mit unterschiedlichen OGL- und Vulkan-Treibern von unterschiedlichen Treiber-Teams.
Anfangs gab es nicht einmal Vulkan-Treiber für Windows.
Gab es schon recht lange, nur nicht offiziell. Ein proprietärer Treiber für eine schlanke API für die wichtigste Plattform sollte die Intel-Entwickler vom Aufwand her auch nicht gerade vor unlösbare Aufgaben stellen. Zumal unter Windows man auch abseits von Gen9 null Aufwand aufgebracht hat.

Edit: Hitman DX12 zeigte hier btw. mit Intel auch die stärkste Einbuße gegenüber DX11.

Loeschzwerg

2018-04-21, 14:50:53

Die besagten 3fps

Zur Info am Rande: Als Szene habe ich gleich den ersten Raum im Spiel verwendet und mich da mit dem Rücken gegen das große Schott gestellt (Blick in Richtung Altar und dem Tor zum Anzug). Edit: So wie im ersten Bild hier (https://communities.intel.com/message/405738#405738).

Die Werte sind zumindest bei mir reproduzierbar.

Locuza

2018-04-21, 15:38:22

Wenn man schon (lange) FL12_1 hat, sollte auch irgendwo die Performance bei dieser oder ähnlicher API stimmen. Die besagten 3fps sind für Intel-Verhältnisse sicherlich auch prozentual eine echt hässliche Einbuße, auch verglichen mit Nvidia.
Indem Aspekt hat FL12_1 keine Bedeutung, da Rendering-Features Conservative Rasterization Tier 1 und Rasterizer Ordered Views Pflicht sind, die aktuell noch kein Spiel direkt über DX12 verwendet und ohne Verwendung natürlich auch keine Auswirkung in der Praxis.
Doom verwendet auch nichts ähnliches unter Vulkan, dort gibt es Conservative Rasterization erst seit kurzem als Erweiterung und ein ROV-Gegenpart lässt sich noch Zeit.

Was ich persönlich als LL-Features definieren würde, sind die Hardware-Limits bei der Verwaltung der Ressourcen und wie die Hardware die unterschiedlichen Queue-Typen implementiert, weil das Kernelemente sind, die unter LL-APIs zum Zuge kommen könnten.
Jedenfalls bei Vulkan melden die Linux-Treiber fast keinen Unterschied bezogen auf die Limits bei Skylake Gen9 gegenüber Haswell Gen 7.5 zurück:
https://vulkan.gpuinfo.org/displayreport.php?id=3038#limits
https://vulkan.gpuinfo.org/displayreport.php?id=3052#limits

3D- und Compute-Queue laufen bisher bei keiner Intel Hardware simultan ab und die DMA-Engine wird laut Intel nicht in allen Fällen von einer möglichen Copy/Transfer-Queue verwendet.

Da gibt es keine low-hanging-fruits die man teilweise ausnutzen könnte, wie wenigstens AMD mit Async Compute und möglicherweise leichtem CPU-Limit.
Die abstrahierten Teile müssen vom Treiber sauber optimiert werden und die App muss dann effizientere Methoden verwenden und den Treiber z.B. dank explizitem ressource management schlagen, der teilweise gezwungen ist konservativ vorzugehen, um keine Konflikte zu riskieren.

aufkrawall

2018-04-21, 18:08:55

Multi-Queue bringt auf Nvidia auch so gut wie nichts, und trotzdem läuft es ohne Schatten auf Nightmare-Qualität quasi gar nicht langsamer als OGL im GPU-Limit, obwohl NV's OGL-Treiber für Doom totoptimiert wie sonst was sein dürfte (im Gegensatz zu Intels).
Mir ist kein Fall bekannt, wo Intel mit LL im GPU-Limit nicht am meisten verlieren würde. Wahrscheinlich krankt es bei den Fähigkeiten der Treiber-Entwicklung genau so wie bei der GPU-HW, wenn man das überhaupt so trennen kann...
Die Linux-Treiber sind besser, was Bugfreiheit bei 3D-Rendering angeht. Bez. Speed im GPU-Limit würd ich da aber auch keine Wunder erwarten.

gravitationsfeld

2018-04-21, 19:28:50

Die Khronous Group hat intern eine Anfrage gepinned bezüglich einem ROV-Äquivalent unter Vulkan:
https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/27

Ich habe gar nicht gewusst, dass Lumberyard ROVs für OIT implementiert hat:
https://docs.aws.amazon.com/lumberyard/latest/userguide/images/shared-OIT-example-animation.gif
https://docs.aws.amazon.com/lumberyard/latest/userguide/graphics-rendering-order-independent-transparency.html

Würde mich freuen, wenn Conservative Rasterization und ROVs nach all den Jahren weitflächig Verwendung finden, aber leider hat das ganze Thema sehr lange gedauert und Polaris ohne Support und "Vega M" helfen leider auch von der Hardwareseite nicht. :P
ROVs sind immer noch viel zu lahm um praktikabel zu sein. Das wird sich vorraussichtlich auch nicht aendern.

Einfach mal als Einwurf, weil ich mich daran erinnere das gravitationsfeld bei DX12 das Resource-Binding-Tier 3 unter Maxwell/Pascal in Frage gestellt hat, was offensichtlich die Hardware-Limits überschritten hat.
Die gerade neusten Vulkan-Treiber von Nvidia gehen auch über die Hardware-Limits und Nvidia fasst es so zusammen:
https://abload.de/img/nvagrm0.jpg

Die Ursprungsquelle:
https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/26
Gleiches Problem wie bei DX12. Der Treiber faellt nach 16k Eintraegen in einem Array auf shader storage buffer fuer die Texture-Handles zurueck anstatt constant buffer zu benutzen und die Performance bricht ein.

Immerhin dokumentiert NVIDIA das Verhalten dieses Mal. Bei DX12 haben sie einfach nichts gesagt und alle ins Messer rennen lassen.

Multi-Queue bringt auf Nvidia auch so gut wie nichts
Was ist "Multi-Queue"? Bisher hab ich "Multi-Queue" nur in Foren gelesen und es wurde immer von Trotteln verwendet. NVIDIA hat Probleme mit Asynchronous Compute, aber DMA-Transfers sind auch auf einer "Queue" und das funktioniert so wie es soll.

gmb

2018-04-21, 20:05:29

Digidi

2018-04-22, 02:09:40

Was ist "Multi-Queue"? Bisher hab ich "Multi-Queue" nur in Foren gelesen und es wurde immer von Trotteln verwendet. NVIDIA hat Probleme mit Asynchronous Compute, aber DMA-Transfers sind auch auf einer "Queue" und das funktioniert so wie es soll.

Ich glaube da ist das damit gemeint:

Of course to pull this off you need hardware that can support executing work from multiple queues, and this is something that AMD invested in early.

https://www.anandtech.com/show/9124/amd-dives-deep-on-asynchronous-shading

gravitationsfeld

2018-04-22, 05:35:58

Ich weiss schon was er meint, nur ergibt es keinen Sinn.

Uebrigens ist das erste Schaubild in deinem Link bisschen taeuschend. Die Transfer-Queues wurden vom Treiber durchaus auch in DX11/OpenGL benutzt.

Locuza

2018-04-22, 06:15:29

ROVs sind immer noch viel zu lahm um praktikabel zu sein. Das wird sich vorraussichtlich auch nicht aendern.
Das wäre schade, wenn in der Praxis das Ganze im Sand verläuft, ähnlich wie bei Geometry-Shaders und Tessellation, weil die Spec und/oder die Hardware suboptimal für praktische Anwendungsfälle ausfällt.

TressFX1.0 hat OIT mit Linked-Lists und unbounded memory umgesetzt und die Version war noch unoptimiert und hat auch Geometry-Shaders verwendet, die man später mit Vertex-Shaders ersetzen konnte.
Laut AMD hat das Hair-Rendering mit Version 2.0 nur noch grob die Hälfte gekostet.
https://www.computerbase.de/2013-11/haare-schneller-rendern-mit-amd-tressfx-2.0/

Bei Tomb Raider 2013 (1.0 Version) hat es noch 30% Performance gekostet:
http://www.pcgameshardware.de/screenshots/original/2013/03/Tomb-Raider-GPU-Benchmarks-integrated-TressFX.png
http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Tests/Tomb-Raider-PC-Grafikkarten-Benchmarks-1058878/

ROVs bieten immerhin die Möglichkeit an, ohne unbounded memory und die Performance unter Grid 2 war für die Raucheffekte annehmbar (-23%) dafür das es nur eine Haswell GT3 iGPU mit eDRAM war:
https://software.intel.com/sites/default/files/managed/69/44/codemasters-grid2-with-intel-avsm-sample.png
https://www.computerbase.de/2013-07/intel-iris-pro-5200-grafik-test/7/

Es gab damals Ausführungen von Intel und auch AMD, die meinten das Nvidia und AMD es schwer(er) haben werden in ihrem Pixel-Backend-Design etwas Vergleichbares umzusetzen wie Intel es mit PixelSync getan hat, aber das ist nun ein offizieller Standard unter DX12 mit ROVs geworden, deswegen war und bin ich gespannt, wie die Performance unter modernen GPUs und zwischen den Hardwareherstellern ausfällt.

Gleiches Problem wie bei DX12. Der Treiber faellt nach 16k Eintraegen in einem Array auf shader storage buffer fuer die Texture-Handles zurueck anstatt constant buffer zu benutzen und die Performance bricht ein.

Immerhin dokumentiert NVIDIA das Verhalten dieses Mal. Bei DX12 haben sie einfach nichts gesagt und alle ins Messer rennen lassen.
Die Alternative wäre dann aber, dass man seine Anwendung speziell limitieren müsste bzw. die Anwendung dann abschmieren würde, wenn man über das Limit geht?

pixeljetstream

2018-04-22, 11:56:41

in dem gtc link vorhin hatte ich paar andere Techniken mit bounded memory gezeigt, welche die ersten N Layer sortieren und den Rest dann approximieren. Man kann gerade bei Rauch auch über Varianten von dem "weighted blended OIT" sehr günstig solche Effekte umsetzen. Letztendlich approximiert man mit der ROV Methode ja auch immer noch.
Es ist halt ungünstig ein ordering in nem system was sonst out-of-primitive-order die shader abarbeitet zu erzwingen. Ich meine Intel arbeitet mit kleinerer Granularität beim kombinieren von quads in Threadgruppen. Bei NV sinds 32 und AMD 64, das heißt es können verschiedene Dreiecke in der gleichen Gruppe sein, was das Einhalten des Orderings nochmal extra ungünstig macht.
Vor ROV, musste sich halt nur ROP am Ende um das einhalten des Orderings kümmern, und so konnte man shader execution von blending etc. schön entkoppeln.

Was die Sache mit den hw limits angeht, zeigt halt einmal mehr dass dieses "Low-Level" Gerede übertrieben ist ;) DX12/VK sind modernisierte aber abstrakte APIs wie vorher auch, der Entwickler kann nun expliziter ausdrücken was er vor hat. Aber die wirtschaftliche Realität siegt am Ende, Treiber und Hardware werden an das angepasst was vorherrscht. In 15 Jahren sind die Treiber dann wieder genauso komplex um alle möglichen Anwendungen und Hardwaregenerationen zu erschlagen, und dann gibt's den nächsten überfälligen cut oder so :)

fondness

2018-04-22, 14:50:07

Die Alternative wäre dann aber, dass man seine Anwendung speziell limitieren müsste bzw. die Anwendung dann abschmieren würde, wenn man über das Limit geht?

Was bringt es, ein Feature auf dem Papier zu unterstützen, dass dann aber wegen einer reinen Softwarelösung zu langsam für die Praxis ist? Das ist vielleicht gut für die Marketingabteilung und die Checkliste, aber viel mehr auch nicht. Ich finde es schade, dass NV selbst bei den LL-APIs schon wieder anfängt Abstraktionsebenen einzubauen und damit Unterstützung für etwas vorgaukelt, dass die HW einfach nicht hergibt.

gravitationsfeld

2018-04-22, 16:46:50

ROVs bieten immerhin die Möglichkeit an, ohne unbounded memory und die Performance unter Grid 2 war für die Raucheffekte annehmbar (-23%) dafür das es nur eine Haswell GT3 iGPU mit eDRAM war
ROVs sind auf Intel-Chips am schnellsten, weil sie viel weniger Ausfuehrungseinheiten haben.

Was die Sache mit den hw limits angeht, zeigt halt einmal mehr dass dieses "Low-Level" Gerede übertrieben ist ;) DX12/VK sind modernisierte aber abstrakte APIs wie vorher auch, der Entwickler kann nun expliziter ausdrücken was er vor hat. Aber die wirtschaftliche Realität siegt am Ende, Treiber und Hardware werden an das angepasst was vorherrscht. In 15 Jahren sind die Treiber dann wieder genauso komplex um alle möglichen Anwendungen und Hardwaregenerationen zu erschlagen, und dann gibt's den nächsten überfälligen cut oder so :)
Ich finde das nicht verkehrt, dass man groessere Brueche in den APIs hat um sich der Hardware-Realitaet anzupassen.

Vulkan ist aber auch immer noch um Magnituden naeher an der Hardware dran als OpenGL/DX11, ich finde das Narrativ von "kein Low-Level" arg uebertrieben. Auf GCN ist es naeher an der Hardware als bei NVIDIA, das liegt aber eher an "komischer" NV-Hardware, als an der "wirtschaftlichen Realitaet".

Was bringt es, ein Feature auf dem Papier zu unterstützen, dass dann aber wegen einer reinen Softwarelösung zu langsam für die Praxis ist? Das ist vielleicht gut für die Marketingabteilung und die Checkliste, aber viel mehr auch nicht. Ich finde es schade, dass NV selbst bei den LL-APIs schon wieder anfängt Abstraktionsebenen einzubauen und damit Unterstützung für etwas vorgaukelt, dass die HW einfach nicht hergibt.
In dem Fall ist es schon okay, weil man sonst gar keine Moeglichkeit hat z.B. viele Texturen in einem Array zu indizieren. Das war lustigerweise mit ARB_bindless_texture in OpenGL sogar lower level als Vulkan/DX12.

pixeljetstream

2018-04-22, 17:48:42

Ich finde das nicht verkehrt, dass man groessere Brueche in den APIs hat um sich der Hardware-Realitaet anzupassen.

Vulkan ist aber auch immer noch um Magnituden naeher an der Hardware dran als OpenGL/DX11, ich finde das Narrativ von "kein Low-Level" arg uebertrieben. Auf GCN ist es naeher an der Hardware als bei NVIDIA, das liegt aber eher an "komischer" NV-Hardware, als an der "wirtschaftlichen Realitaet".

Ja ich finde auch nen Bruch ist immer Mal notwendig und finde auch man hat mit Vk viel richtig gemacht. Aber dennoch hab ich das Gefühl dass der LL Begriff überstrapaziert wird, es ist keine Treiberentwicklung für N Hersteller.

Wirtschaftliche Realität im Sinne davon dass es durchaus Entwickler gibt die lieber ein Pfad implementieren als mehrere und man mit so layer entgegen kommt und mehr hw erreicht wird. Hauptsache es wird irgendwo dokumentiert. "Komisch" ist relativ, für eine hw mit state machine ist ein "PSO" auch komisch und im Prinzip ineffizienter als inkrementelle state updates, oder diverse resource transitions die es nicht braucht, sind aus Anwendersicht auch doof ;) Es ist immer ein Kompromiss.

Hübie

2018-04-22, 17:53:03

Moment mal. Hab ich das jetzt richtig verstanden, dass ROVs auf NV eine reine Softwarelösung sind? :|

pixeljetstream

2018-04-22, 18:44:23

nein, es sind zwei unterschiedliche Themen. Einmal warum ROVs allgemein nicht der hit sind, und einmal das Anheben der binding limits bei NV.

Hübie

2018-04-22, 18:50:00

Was ist denn der ausschlaggebende Faktor in welcher Reihenfolge Vertex Daten übermittelt werden?

gravitationsfeld

2018-04-22, 23:26:10

Ja ich finde auch nen Bruch ist immer Mal notwendig und finde auch man hat mit Vk viel richtig gemacht. Aber dennoch hab ich das Gefühl dass der LL Begriff überstrapaziert wird, es ist keine Treiberentwicklung für N Hersteller.

Wirtschaftliche Realität im Sinne davon dass es durchaus Entwickler gibt die lieber ein Pfad implementieren als mehrere und man mit so layer entgegen kommt und mehr hw erreicht wird. Hauptsache es wird irgendwo dokumentiert. "Komisch" ist relativ, für eine hw mit state machine ist ein "PSO" auch komisch und im Prinzip ineffizienter als inkrementelle state updates, oder diverse resource transitions die es nicht braucht, sind aus Anwendersicht auch doof ;) Es ist immer ein Kompromiss.
NV Hardware hat tendenziell auch mehr state als GCN und/oder kommt mit state changes besser zurecht. Und Vulkan hat ja zumindest einiges als dynamischen State als opt-in, bei DX12 ist der depth bias fest in den PSOs :ugly:

dildo4u

2018-04-25, 15:26:46

Nvidia WHQL Treiber für Vulkan 1.1.

https://www.forum-3dcenter.org/vbulletin/showthread.php?t=587967

aufkrawall

2018-04-25, 16:38:34

Nur über einen Monat nach AMD im Consumer-Treiber, aber Nvidia hat ja bekanntlich nicht so viel Geld. :cool:

Kartenlehrling

2018-05-02, 18:28:42

https://www.khronos.org/assets/uploads/events/2018-vulkan-developer-day-banner.jpg
https://www.khronos.org/events/2018-vulkan-developer-day-in-montreal
2018 Vulkan Developer Day in Montréal

Hoffentlich trägt es auch Früchte wenn diese Präsentationen im Ubisoft Haus statt fand.

Gast

2018-05-02, 20:51:24

Hoffentlich trägt es auch Früchte wenn diese Präsentationen im Ubisoft Haus statt fand.
Sie haben nach internen Tests nur 5% GPU, aber dafür 30-40% CPU Mehrleistung unter Vulkansupport, ich denke - ja.

aufkrawall

2018-05-03, 23:23:51

Gibt mit Nvidia und dem RotTR-Port offenbar ein paar Probleme mit dem Ressourcenmanagement bzw. knappem VRAM:
https://www.gamingonlinux.com/articles/rise-of-the-tomb-raider-has-a-new-opt-in-beta-to-help-with-nvidia-issues.11686
Den Comments von dort entnehme ich auch, dass die Treiber vor r396 (gabs nur als Beta, als der Port erschienen ist) mit dem alten Shader Compiler den Speicher vollmüllen.

Nennenswerte Probleme mit radv ab Polaris habe ich nicht gelesen.

Kartenlehrling

2018-05-08, 09:35:14

http://on-demand.gputechconf.com/gtc/2018/presentation/s8521-advanced-graphics-extensions-for-vulkan.pdf
NVIDIA RTX: Enabling Ray Tracing in Vulkan, Ray Traced Ambient Occlusion (RTAO)

Locuza

2018-05-10, 13:31:54

Die UE4 Vulkan Präsentation ist online, die kurz auf die Verbesserungen vom Vulkan Renderer eingeht und wie die Arbeitsweise im Laufe der Zeit optimiert wurde:
https://twitter.com/RCalocaO/status/993879127445958656

Mittlerweile schlägt der VK-Pfad AMDs DX11 Render-Thread bei der Single-Thread Performance um ~30% in der Infiltrator Demo.

In der Zukunft möchte man Vulkan 1.1 und MultiGPUs unterstützen und viel gravierender, den High-Level-Renderer so umstellen, dass es für DX12/Vulkan ein passendes Engine-Design darstellt.
Das wird sicherlich lange dauern.

Kartenlehrling

2018-05-10, 13:39:00

Kann man eine eigenständige Vulkan Demo irgendwo downloaden,
die HDR DX12 Demo von Nvidia gab es auch nur auf der E3 2017 zu sehen?!!

SaschaW

2018-05-10, 13:46:33

Es gibt noch keinen öffentlichen Treiber mit Support für die Vulkan Raytracing Extensions, also nein.

Ganon

2018-05-13, 11:57:14

Dafür, dass das Projekt gerade mal ~8 Monate alt ist, macht der DX11->Vulkan Wrapper DXVK sehr gute Fortschritte:

https://github.com/doitsujin/dxvk

Beispiele finden sich reichlich auf YouTube:
https://www.youtube.com/results?search_query=dxvk+wine

aufkrawall

2018-05-13, 14:27:03

Es findet auch eine fruchtbare Zusammenarbeit mit Treiber-Entwicklern statt, sogar mit Nvidia. :redface:

Ganon

2018-05-23, 21:44:05

Eine erste Version von WINEs DX12 -> Vulkan Library ist verfügbar und führt (angeblich) bereits erste DX12 Demos aus: https://www.winehq.org/news/2018052301

Kartenlehrling

2018-06-04, 07:54:00

Als Vulkan für dota2 windows präsentiert wurde habe ich es geteste, wirklich besser lief es da aber nicht.
Nun soll es eine Vulkan für MacOS geben und es dafür wohl sinnvoll sein.

Jetzt verfügbar: Vulkan-Unterstützung für DOTA2 auf MacOS, was zu verbesserter Performance und Frame-Time-Stabilität führt.
Aktiviere den "Vulkan support" -DLC in Steam, danach wechsln sie zu Vulkan in den Videoeinstellungen
https://github.com/ValveSoftware/Dota-2-Vulkan

gravitationsfeld

2018-06-04, 18:29:26

"Vulkan"-Version. Das benutzt den Metal-Wrapper.

aufkrawall

2018-06-04, 19:24:27

Unter Windows und Linux laufen OGL und Vulkan in dem Spiel jedenfalls noch immer genau so kacke wie vorher, Shadercompile-Stuttering aus der Hölle...

gravitationsfeld

2018-06-04, 21:20:55

Das ist aber ganz allein Valves fail.

Locuza

2018-06-04, 21:43:15

Source 2 unterstützt auch noch DX9, wo DX9 in gewissen Fällen sogar der schnellste Pfad ist.
Bei der Vulkan-Umsetzung und wohl auch generell technisch, war offensichtlich das Valve ganz primitive Technik umsetzt, relativ zu dem Top-Zeug in der Industrie.

Ganon

2018-06-04, 22:00:07

gravitationsfeld

2018-06-04, 22:19:13

Viel Spass das den ganzen CAD-Herstellern zu erklaeren. Die straeuben sich seit 20 Jahren irgend was selbst zu neuerem OpenGL zu migrieren.

Die werden vorher wahrscheinlich eher auf macOS verzichten.

Ganon

2018-06-04, 22:35:34

Vielleicht baut ja jemand noch ein OpenGL -> Metal Framework. Wenn nicht, dann haben sehr viele Leute ein Problem, sofern Apple den Schnitt dann macht. Ein Großteil der Steam-Library wird inkompatibel, OpenSource Software wie Blender wird, sofern sie keine Metal-Maintainer finden, wird nicht mehr funktionieren...

Das kann noch echt lustig werden. Fragt sich wie viel Zeit Apple den Leuten so lässt.

gravitationsfeld

2018-06-04, 23:20:46

Ich mein, ich versteh es, dass sie den OpenGL-Rattenschwanz nicht mehr haben wollen, aber das ist schon ganz schoen aggressiv mal wieder.

DanMan

2018-06-07, 23:55:32

Vielleicht baut ja jemand noch ein OpenGL -> Metal Framework.
https://moltengl.com/moltengl/

Ist aber (bisher) nur OpenGL ES.

Ganon

2018-06-08, 08:59:06

https://moltengl.com/moltengl/

Ist aber (bisher) nur OpenGL ES.

Gibt's schon eine ganze Weile und wie du ja sagst ist es bisher nur OpenGL ES 2.0. Noch dazu ist es rein kommerziell. ANGLE von Google macht hier ähnliches (für Browser hauptsächlich): https://github.com/google/angle

Aber das ist halt alles nur WebGL/OpenGL ES 2.0 (also Feature Level OpenGL 2.0 / DX9). Das ist noch ein ganz großes Stück entfernt von OpenGL 4.6. Und solange es (im Fall von MoltenGL) rein kommerziell ist, ist es auch nutzlos.

SaschaW

2018-06-08, 17:40:25

https://moltengl.com/moltengl/

Ist aber (bisher) nur OpenGL ES.

MoltenVK ist Vulkan auf Metal. Ja, auch kommerziell, wird aber von einigen Studios für Ports schon genutzt.

Und das Apple jemals auf Vulkan setzen ist unwahrscheinlich. Auch wenn es was eigenes ist, Metal ist eine gute API und v.a. das Tooling ist sehr schick, z.B. der neue zeilenweise Shader-Debugger.

Ganon

2018-06-08, 18:26:36

MoltenVK ist Vulkan auf Metal. Ja, auch kommerziell, wird aber von einigen Studios für Ports schon genutzt.

MoltenVK wurde mit Hilfe von Valve Open Source gestellt und ist kostenlos:
https://github.com/KhronosGroup/MoltenVK

gravitationsfeld

2018-06-09, 05:10:35

Mit Hilfe = Valve hat nen Geldsack rueber wandern lassen ;)

MoltenVK ist Vulkan auf Metal. Ja, auch kommerziell, wird aber von einigen Studios für Ports schon genutzt.
Einige? Ich dachte bisher nur Dota 2 oder weisst du von mehr?

pixeljetstream

2018-06-09, 08:13:10

CAD spielt auf Mac keine Rolle, das sind andere professionelle Apps die da getroffen werden (M&E). Ich find's super :) endlich ist opencl offiziell vom Macher tot erklärt, und die feature bremse Mac GL ist auch weg.

gravitationsfeld

2018-06-09, 08:34:49

Was ist denn die Alternative zu OpenCL? CUDA ja, ist aber Vendor spezifisch.

OpenCL/SYCL-Kernel auf Vulkan laufen lassen?

Ganon

2018-06-09, 08:37:32

Was ist denn die Alternative zu OpenCL?

Laut Apple der Compute Part von Metal. Wobei sie es soweit ich weiß nirgendwo direkt sagen. https://developer.apple.com/videos/play/wwdc2017/608/?time=59

edit: Vielleicht verbieten sie ja auch irgendwann CUDA. Das wäre dann auch mal ein Schritt :D

Menace

2018-06-09, 08:56:39

Mit macOS 10.14 / iOS 12 sind dann übrigens OpenGL, OpenCL und OpenGL ES deprecated. D.h. das wird dann vermutlich in 10.15 oder 10.16 rausfliegen. Dann wird MoltenVK der einzige Weg sein, wenn man nicht direkt Metal nutzen will.

What? OpenCl nicht mehr auf macOS? Was machen dann die C1-Nutzer (RAW-Konverter) bzw die doch relativ kleine Gruppe der Software-Entwickler? Ich würde ja denen empfehlen zu Windows zu wechseln. :biggrin:

Troyan

2018-06-09, 09:44:13

aufkrawall

2018-06-09, 11:12:13

Unterstützt(e) AMD denn überhaupt OCL 2.0 auf dem Mac? Unter Linux ist das nämlich (noch) nicht der Fall.
Wär dann auch nachvollziehbar, dass Apple nicht mehr diese verschleppte Entwicklung will.

Menace

2018-06-09, 11:40:55

Was machen aber Hersteller, die Plattformübergreifend Software anbieten möchten und dabei nicht die Ressourcen von Adobe haben?

pixeljetstream

2018-06-09, 11:42:03

Nein haben sie nicht (Cl 2.0).
Imo ist Vulkan als runtime die alternative zu ocl. Das ist auch eine offizielle Richtung von khronos. Mit clspv gibt es auch ein Projekt dazu (Google, Adobe, Codeplay). Dann müsste die Industrie mittels MoltenVK halt genug Druck auf Apple aufbauen.

Positiv an dem Ganzen ist, dass der Bedarf an guten Programmierern in dem Bereich damit wächst und Firmen die voll auf neuen Softwarestack setzen (Dx12, vk, metal) Chancen haben.

gravitationsfeld

2018-06-09, 17:45:06

Laut Apple der Compute Part von Metal. Wobei sie es soweit ich weiß nirgendwo direkt sagen. https://developer.apple.com/videos/play/wwdc2017/608/?time=59

edit: Vielleicht verbieten sie ja auch irgendwann CUDA. Das wäre dann auch mal ein Schritt :D
Ich meinte generell. macOS interessiert doch niemand der tatsächlich HPC machen will.

Positiv an dem Ganzen ist, dass der Bedarf an guten Programmierern in dem Bereich damit wächst und Firmen die voll auf neuen Softwarestack setzen (Dx12, vk, metal) Chancen haben.
Der ist doch sowieso untersaettigt.

Ganon

2018-06-09, 18:10:11

Ich meinte generell. macOS interessiert doch niemand der tatsächlich HPC machen will.

Mal ganz pessimistisch vermutet: Wenn sie Vulkan um OpenCL Kernel Ausführung erweitern, dann wird das vermutlich optional und NVidia wird's nicht implementieren :ugly:

Ansonsten ist OpenCL weiterhin der Weg im HPC-Bereich, wenn man nicht gerade NVidia zu tun hat.

gravitationsfeld

2018-06-09, 19:05:14

Die noetigen Erweiterungen sind fester Bestandteil von Vulkan 1.1.

danarcho

2018-06-11, 11:29:58

Ich find's super :) endlich ist opencl offiziell vom Macher tot erklärt, und die feature bremse Mac GL ist auch weg.
:| Darüber kann man sich wohl nur als Nvidia-Mitarbeiter freuen. Apple ist vielleicht Erfinder, aber "Macher" sind sie lange nicht mehr.

@gravitationsfeld:
Sicher? Vk 1.1 erlaubt aus OpenCL C++ mit Klassen, templates, lambdas, dynamic parallelism etc gebaute compute kernel zu launchen?

Angenommen, man kommt mit den Features der compute kernel aus (viele benutzen ja noch OpenCL 1.2), hat man immer noch die deutlich komplexe Host API.

Eigentlich hat OpenCL "zuletzt" riesen Sprünge gemacht mit SyCL, C++ und SPIR-V. Was noch fehlt, sind ordentliche Treiber (Hallo Nvidia :P) und ein paar mehr Compiler, die SPIR-V target support haben.

Ganon

2018-06-11, 12:15:21

Wie oben schon genannt wurde gibt es clspv, was OpenCL 1.2 auf Vulkan abbildet... bei genauen hinsehen aber "ein Subset von OpenCL 1.2", eben genau das was Vulkan Compute "so eben günstig" abbilden kann. Mag für einige reichen, aber brauchst halt wieder irgend ein 3rd Party Ding, was dir überhaupt die Möglichkeit dazu gibt. Außer du willst erst mal 2000 Zeilen Code schreiben, bevor du irgendwie Kernel überhaupt starten kann.

Im Grunde: Wir drehen uns drei mal im Kreis und freuen uns, dass wir Fortschritte gemacht haben. Stehen aber jetzt sogar noch mit weniger Features da, als wir vorher hatten.

NVidia kann sich darüber freuen, dass man OpenCL weiterhin auf 1.x Niveau halten kann. Ist dann keine Gefahr für CUDA.

pixeljetstream

2018-06-11, 19:49:05

Afaik ist SYCL auch 3rd party, in diesem Fall vom gleichen wie clspv. Codeplay.

Das ist halt das grundsätzliche Problem hier. Irgendwer muss das drumherum bezahlen. Und solange kein ganz großer dahinter steht (Google, MS, Apple) der als Platformhalter Druck erzeugt und Geld investiert, wird's eng.
Daher imo nun mit vulkan als Basis mehr Chance, da ist zumindest Google mit Interesse.

gravitationsfeld

2018-06-11, 20:10:09

Sicher? Vk 1.1 erlaubt aus OpenCL C++ mit Klassen, templates, lambdas, dynamic parallelism etc gebaute compute kernel zu launchen?
Alles ausser dynamic parallelism sind Compiler-Features, hat nichts mit der Runtime zu tun.

VK_KHR_variable_pointers ist alles was man dafuer braucht.

Ganon

2018-06-11, 21:49:24

Daher imo nun mit vulkan als Basis mehr Chance, da ist zumindest Google mit Interesse.

Ja gut... ist ja auch irgendwo logisch, wenn der marktführende GPU-Hersteller den Standard nicht oder nur _sehr_ träge umsetzt. Hat immerhin 4-5 Jahre gedauert, bevor sie OpenCL 1.2 Support hatten. Spezifiziert 2011, implementiert 2015/16.

Der aktuelle Weg "wir schmeißen alles nach Vulkan" wird ja nur gegangen, weil man eben u.a. von NVidia keine aktuelles OpenCL Ökosystem erwarten kann. Aus ähnlichem Grund wird sich auch um MoltenVK bemüht, weil man eben auch von Apple nicht erwarten kann, dass sie noch mal Vulkan implementieren. Und ebenso wird wohl auch an einem Vulkan -> DX12 Layer gearbeitet, weil man eben auch von MS nicht erwartet, dass sie bei ihren ARM-Varianten Vulkan unterstützen.

Jetzt ist auch geplant, dass man die Compute-Funktionalität von Vulkan erweitert, jedoch scheinbar auch ganz oder teilweise optional, damit man Vulkan nicht verfettet. Und jetzt muss man eben sehen was damit so passiert. Und so wirklich vorwärts sind wir nun seit 2011 auch nicht gekommen.

Insgesamt ist die aktuelle Situation um die offenen Standards eher sehr ernüchternd. Und Vulkan scheint ja aktuell auch den gleichen Weg zu gehen wie OpenGL (minus Apple Support).

aufkrawall

2018-06-11, 22:15:32

Jedenfalls kräht auf Windows außer idTech kein Hahn danach. In der OGL-Geschichte ist aber schon einiges verdammt schief gelaufen, die Parallele zu Vulkan würd ich noch lange nicht ziehen. Wobei OGL mit vernünftigen Spec-konformen Treibern (sprich Mesa) und ohne das GLES-Massaker sicherlich auch nicht so furchtbar ist wie sein Ruf.
Der mäßige Erfolg von Vulkan und OCL ist natürlich auch mit der schleppenden Adaption neuer Techniken im Consumer-Bereich allgemein zu sehen.

pixeljetstream

2018-06-11, 23:15:54

Ganon imo liegt die Verantwortung für das Wohl des CL Ökosystem nicht bei NV. Von einer Standardisierung profitiert in erster Linie der Platformhalter, also muss er sich um das Ökosystem kümmern. Apple war der Platformhalter, hat aber selbst ja auch kein cl2.0 mehr gemacht.
Dass NV erst so spät mit cl1.2 kommen konnte, zeigt ja dass Cl einfach keine so große Bedeutung hatte. Bei Vk oder Dx ist der Druck ein anderer, weil aktives Interesse und Investitionen der Großen vorliegt.

Ganon

2018-06-12, 01:23:20

Klar hatte OpenCL für NVidia keine große Bedeutung... sie haben ja das hauseigene CUDA. ;)

Letztendlich leidete OpenCL gleichzeitig mit AMD, da AMD nicht in der Lage war eine konkurrenzfähige OpenCL Implementierung zu bringen. Das spielte natürlich auch NVidia in die Karten weswegen man vermutlich auch dann relativ zügig jedwede OpenCL "Bemühungen" einstellte.

Auch hatte Apple OpenCL 1.2 Support in etwa 2-3 Jahre früher in OSX drinnen, als NVidia das in ihren anderen Treibern angeboten hat. Das fing also auch schon wesentlich früher an mit "NVidia macht nicht mit" und nicht erst mit 2.0. Und letztendlich hatte auch Apple dann langfristig keinen Plan mehr eine offene Plattform zu sein. OpenGL 4.1 und OpenCL 1.2 kamen gleichzeitig bei Apple und waren beide die letzten Versionen für immer.

Und warum ein NVidia Mitarbeiter "auf dem Working Group Chair" von OpenCL sitzt verstehe ich auch nicht, wenn OpenCL doch angeblich so bedeutungslos ist. Gut, der Verschwörungstheoretiker in mir sagt jetzt natürlich "so kann man die API effektiver sabotieren", aber das will ich jetzt mal nicht sagen ;)

Naja, letztendlich ist der Zug jetzt eh abgefahren. OpenCL in der ursprünglichen Form dürfte tot sein. Ein Revival könnte ich mir nur vorstellen wenn entweder Intel konkurrenzfähige Grafikkarten baut, oder ARM CPUs eine größere Rolle spielen.

Dass Vulkan hier irgendwas ändert, muss sich erst mal zeigen. Während Metal und DX12 schon diversen Support verschiedener Hersteller hat, hat Vulkan nur idSoftware als nennenswerten "Supporter". Ansonsten noch ein paar Titel für Linux-Ports die per Source-Wrapper entstanden sind. Also quasi identische Situation wie zu OpenGL damals (Minus Apple). Valve unterstützt Vulkan zwar auch (siehe MoltenVK), aber sie fangen nicht allzu viel damit an.

gravitationsfeld

2018-06-12, 01:31:29

Dir ist schon klar, dass Androids zukuenftig einzige 3D-API Vulkan ist, ja?

Ganon

2018-06-12, 01:41:39

Dir ist schon klar, dass Androids zukuenftig einzige 3D-API Vulkan ist, ja?

Klar. Aber das war bei OpenGL (ES) davor auch schon der Fall. Und wo hat das jetzt OpenGL zum großen Durchbruch verholfen? Waren jetzt plötzlich alle AAA Produktionen auf allen Systemen deswegen OpenGL basiert? Auch ist OpenCL die einzige Compute-API auf Android... und? Wo ist der OpenCL Durchbruch?

Ich sag ja nicht, dass Vulkan tot ist. Es wird imo nur einfach im großen Markt rund um Spiele und andere 3D Visualisierungen keine große Rolle spielen.

Ich würde es ja schon gerne sehen, dass ich hierbei falsch liege, aber aktuell sehe ich dafür so gut wie keine Anzeichen.

aufkrawall

2018-06-12, 15:38:41

Auch ist OpenCL die einzige Compute-API auf Android...
Compute Shader lassen sich auch via OGL ES nutzen, warum sollte man da in Consumer-Software auf OCL setzen? Für Bildbebarbeitungskram tut es das häufig völlig. Gleiches gilt für den PC, zumal DirectCompute unter DX11 viel besseren Treiber-Support hat. Bescheuertes Interop-Geraffel bleibt so auch aus.

gravitationsfeld

2018-06-12, 18:55:23

Vulkan erfordert sogar Compute-Shader-Unterstuetzung. Ist kein optionales Feature.

Ganon

2018-06-12, 19:22:29

Ihr könnt mich dann ja mal anpingen, wenn ihr auf ein größeres GPGPU Projekt trefft, die Vulkan Compute dafür benutzen.

gravitationsfeld

2018-06-12, 19:28:23

Was soll das jetzt? Du hast das Statement abgegben, dass OpenCL die einzige Compute-API auf Android ist. Was falsch ist. Es gibt mindestens zwei andere.

aufkrawall

2018-06-12, 19:29:51

Bei HPC wird OCL sicherlich noch eine Zukunft haben, anders sind die Bemühungen von sowohl AMD als auch Intel ja nicht zu erklären. Nachdem jetzt der rocm-Kram upstream im Linux-Kernel ist, folgt dann hoffentlich recht bald auch die >1.2-Unterstützung im Userspace. Intel hat ja schon 2.1-Support sowohl unter Windows als auch Linux.

pixeljetstream

2018-06-12, 19:58:09

Vulkan ist bei Android die zukünftige primär APU. Google gehört ja nicht ohne Grund zum clspv Sponsor.

gravitationsfeld

2018-06-12, 20:01:49

Ganon

2018-06-13, 08:34:42

Was soll das jetzt? Du hast das Statement abgegben, dass OpenCL die einzige Compute-API auf Android ist. Was falsch ist. Es gibt mindestens zwei andere.

Tut mir schmerzlich leid, dass ich die beiden vergessen habe. Du darfst mir trotzdem gerne jederzeit berichten, wenn du ein HPC/GPGPU Projekt findest, was darauf aufbaut. Ich kenne aktuell keines, behaupte aber auch nicht, dass es keines gibt.

Die Ursache kann durchaus sein, dass Apple OpenCL bietet, aber keine Compute Shader, eine andere Ursache kann sein, dass OpenGL Compute andere Präzisionsgarantien gibt, noch eine andere Ursache kann sein, dass OpenGL Compute auf GLSL limitiert ist.

Welches davon die Gründe sind... wenn du mehr weißt, gerne raus damit.

Benutzen die nicht eher HIP statt OpenCL?

HIP ist AMDs CUDA, was absolut Port-Unwilligen CUDA-Projekten in ganz großen Schritten entgegen kommen soll. Es ist aber kein Drop-In-Replacement und auch trotz diesen Bemühungen dauern entsprechende Portierungs-Versuche schon recht lange. Die Überzeugungsarbeit "kommt erst mal von CUDA weg" dauert an. Und im HPC-Bereich darfst du denn auch auf sämtlichen Support von NVidia für deinen CUDA-Cluster verzichten, wenn du versuchst das zu benutzen.

AMD hat aber in den letzten Jahren diverse Investitionen vorgenommen, um Projekte auf OpenCL umzustellen. Bei Blender/Cycles hat man z.B. zeitweise 1-2 Mitarbeiter Vollzeit abgestellt die nur daran gearbeitet haben. Auch bei den OpenCL Varianten in Photoshop, Maya oder LibreOffice hatte AMD ihre Finger mit im Spiel.

Das wirft man natürlich auch nicht einfach aus dem Fenster. Entsprechend ist auch AMD weiterhin bemüht eine OpenCL Runtime zur Verfügung zu stellen. Nachdem man es aber scheinbar nach langer Zeit nicht geschafft hat ihre geschlossene 2.0 Runtime OpenSource zu machen (oder nicht wollte, weil echt miserabel kA), hat man halt den Kram allgemein neu implementiert.

Menace

2018-06-19, 09:34:59

Und wie die Konsequenzen bei einer eher kleinen Firma aussehen:

"We are aware of the message from Apple, and given that GPU HW acceleration is a big thing for Capture One, we are investigating our options."

http://forum.phaseone.com/En/viewtopic.php?f=71&t=28419&start=15

Ex3cut3r

2018-06-30, 21:05:40

Doom bzw Vulkan sind im CPU Limit einfach Wahnsinn, ein 4770k @ 1GHz (siehe OSD) ist in der Lage eine GTX 1070 zu 97% auszulasten. Wenn doch jedes Game wenigstens annähend im CPU Limit so genial wäre.

https://abload.de/thumb/doomx64vk_2018_06_30_3ss92.png (http://abload.de/image.php?img=doomx64vk_2018_06_30_3ss92.png)

Im "Kampf" ist es dann mal auf 75% gedroppt, aber das ist auch immer noch genial. Denn @ 1Ghz entspricht es nicht mal der Hälfte eines FX 8350. :eek:

Mit 1GHz stockt selbst Windows etwas im Desktop. Bin wieder im Bios, 4,2 einstellen.

https://abload.de/thumb/farcry5_2018_07_01_03lgs10.png (http://abload.de/image.php?img=farcry5_2018_07_01_03lgs10.png)

Dazu mal als krasses Gegenbeispiel, Far Cry 5 720p Max Details, Ubisoft ist wirklich so eine schlechte Firma wenn es um CPU Limit geht, @ 4,1 spuckt der 4770k nur 70-95 FPS aus mit DDR3 2400 11-13-13-210. Mit einer 1170/1180 werde ich auch in 3440x1440 im CPU Limit sein, super Ubisoft. :uup: Mehr Kerne wurden auch nix bringen, da das Game nur mit Max 4 Threads umgehen kann...

Assains Creed Origins ist sogar noch schlimmer, das spuckt nur 50-70 FPS im CPU Limit aus. Lächerlich, wie gutes DX11 geht zeigt BF1, da passiert so viel teilweise, und habe eigentlich immer 90 - 150 FPS @ DX11. In Operations sie sind aber niedriger als in Conquest, was auch logisch ist, in Operations passiert viel mehr auf engsten raum.

gravitationsfeld

2018-07-01, 06:05:48

Das hat weniger mit den APIs zu tun als mit 60 oder 30 Hz auf den Konsolen.

dargo

2018-07-01, 07:33:15

Naja... sicherlich spielt 60/30Hz eine große Rolle. An der API liegts aber auch, vor allem Assassin’s Creed Origins ist da echt übel an den dicht besiedelten Stellen, zumindest mit Radeon. Da finde ich das Beispiel mit Far Cry 5 noch recht harmlos. Dort ist der CPU Bound nicht soo stark.

gravitationsfeld

2018-07-01, 16:23:09

Schon. Doom verteilt seine Render-Arbeit, das war ein Muss auf den Konsolen. Ein Thread war zu langsam. Das wurde dann halt auch nach Vulkan portiert, auch wenn's eigentlich unnötig war. Ist auch so schnell genug.

aufkrawall

2018-07-14, 13:45:03

Offenbar kann der Nvidia-Treiber gar kein Triple Buffer Vsync? In SS Fusion gibts unterhalb der Refreshrate einfach Tearing, und das war schon in Wolfenstein 2 so (und auch Doom?). Mit AMD ist das zumindest in Fusion nicht so.
Dort hat btw. RadV einen niedrigeren Input Lag als amdvlk & Nvidia.

dildo4u

2018-07-14, 16:24:15

Screemer

2018-07-14, 16:26:21

Du vergleichst völlig verschiedene Games.
Natürlich hat Origins die höste CPU Last da es mit Abstand die meisten NPCs darstellt.Idtech 6 ist z.b für Open World gar nicht zu gebrauchen daher nutzt Rage 2 Apex.
Könnte ja nicht daran liegen, dass es von avalange kommt und dort alle mit apex vertraut sind und nicht mit idtech6...

aufkrawall

2018-07-15, 12:59:08

DXVK hat offenbar kaum CPU-Overhead und MT > 4 Threads geht auch:
https://abload.de/thumb/2dnoml.jpeg (http://abload.de/image.php?img=2dnoml.jpeg)

Leonidas

2018-07-15, 16:16:29

Finde es nichtsdestotrotz erschreckend, wie wenig bislang auf dem PC mit Vulkan passiert ist. Zeit war nun genügend - und das es auch wenig DX12-Games gibt, darf nicht die große Ausrede sein. Immerhin ist Vulkan OS-unabhängig, d.h. es hat eine niedrigere Einstiegshürde als DX12.

Wollen die Spieleentwickler denn ewig DX11 weiter supporten?

Ganon

2018-07-15, 16:40:48

Liegt vermutlich an der fehlenden Notwendigkeit. Klar kann man eine Engine bauen, die mit den klassischen APIs quasi unmöglich wäre, aber scheinbar sieht daran kaum einer einen Bedarf. Auch macht ja DX12/Vulkan die Spiele nicht grundlegend hübscher oder erlaubt grundlegend andere Rendering-Technologien.

AffenJack

2018-07-15, 17:47:48

Jupp, sehe ich auch so. Die CPUs der Konsolen sind dermassen langsam, dass man auch mit DX11 meist genug Performance hat bei den stärkeren CPUs am Desktop. Mit DX12/Vulkan bekommt man im Moment hauptsächlich eine deutlich bessere Unterstützung von Low-End CPUs, aber dafür ist der Entwicklungsaufwand anscheinend für die meisten Entwickler zu hoch. Bei den grafikfeatures ist dagegen dei Kompatibilität das Problem. DX12.1 wird niemand einsetzen, weil man dafür die Engine stark umbauen muss, laut Sebbi bei b3d, und die Konsolen das nicht können.
Ich hatte auf mehr Spiele gehofft, wenn SM6 kommt, aber da entfällt der Support für Kepler und GCN1.0. Ist also auch wieder eine große Hürde für Entwickler. Ich weiß nicht wie vergleichbar das bei Vulkan ist, aber auch da können eben auch nur die Features genutzt werden, die in Hardware da sind. Bleibt größtenteils eben die CPU Entlastung.

aufkrawall

2018-07-15, 19:16:14

Blediator16

2018-07-20, 19:34:28

Async Shader Compiler für RPCS3.

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

gravitationsfeld

2018-07-20, 21:19:30

Das ist keine generische Loesung, du kannst nicht einfach Zeug nicht anzeigen solange es kompiliert. In nem Emulator mag das akzeptabel sein.

aufkrawall

2018-07-24, 14:57:44

Wow, der neue Shader Compiler im Nvidia Entwickler-Treiber killt in einigen Spielen mal eben die Performance. Im normalen Linux Final-Treiber wird der auch schon genutzt. wtf?
Ein völliger Schrotthaufen im Vergleich zu radv. ;D
Weiter gehts:
mpv unter Windows crasht beim Resizen des Fensters, unter Linux ist ein CPU-Thread zu 100% ausgelastet. :uclap:
Überspitzt gesagt läuft gar nichts richtig mit dem Treiber, außer AAA-Spiele. Ein neuer Tiefpunkt der Treiber-"Qualität" bei Nvidia, auch ganz allgemein...

robbitop

2018-07-25, 10:40:07

@PS3 Emu
Ist das Nadelöhr bei Emulatoren nicht idR die CPU? Insofern würde AC doch eher nur der GPU helfen.

Wie gut ist eigentlich die Multicoreskalierung bei diesem Emulator. Wird jeder SPE auf einen eigenen Thread gelegt? Skaliert das ganze somit mit bis zu 8 Threads?

gravitationsfeld

2018-07-25, 10:44:27

Ich geh davon aus. SPEs kann man ziemlich einfach mit Threads emulieren, weil sie nur auf ihren kleinen Scratch-Speicher direkt zugreifen können. Es gibt keine Cache-Kohärenz, alles nach außen geht über DMA.

Ganon

2018-07-25, 11:54:22

@PS3 Emu
Ist das Nadelöhr bei Emulatoren nicht idR die CPU? Insofern würde AC doch eher nur der GPU helfen.

Das Problem ist die Wandlung der Konsolen-Shader auf die Vulkan Shader. Ist also vollkommen egal wie schnell dein PC ist, mitten im Frame große neue Shader kompilieren ist einfach der Performance-Tod.

Das asynchron zu machen hilft halt der Performance, kommt aber mit zeitweiligen Grafikfehlern. Da man den Kram für zukünftige Durchläufe speichern kann, ist das halt eine mehr oder weniger akzeptable Lösung.

robbitop

2018-07-25, 12:04:04

Warum kompiliert man die Shader überhaupt "online"? Wäre es nicht sinnvoller Shader offline zu kompilieren? Kostet dann keine Leistung und das Ergebnis ist sicherlich besser (effizienter). -> man könnte rechenintensivere Optimierungsalgorithmen nutzen oder hier und da per Hand nachtunen.

Ganon

2018-07-25, 12:05:57

robbitop

2018-07-25, 12:12:42

Du sagtest doch, dass man die kompilierten Shader für den zweiten Durchlauf speichern kann? Ergo müsste man pro Spiel doch nur jeweils 1x Durchlauf machen und die kompilierten Shader veröffentlichen (zusammen mit zukünftigen Releases des Emus - oder in einer Datenbank, so dass der Emu auf Wunsch die jeweiligen Shader aus dem Netz laden kann). Dann würde man für alle Neuuser die Artefakte zumindest vermeiden, oder?

Ganon

2018-07-25, 12:14:29

Bei CEMU kann man das machen (obwohl nicht im Emulator mitliefern, wegen Copyright-Problematik). Dort kann man einen Shader-Zwischenschritt behalten/austauschen/.... Aber trotzdem muss jemand im Vorfeld das Spiel (also wirklich jedes Einzelne) quasi durchspielen für jede neue Emulator-Version. Das ist praktisch einfach nicht machbar.

robbitop

2018-07-25, 12:17:56

Ganon

2018-07-25, 12:19:08

Kann man doch die User machen lassen. Der erste, der es spielt, läd es automatisch hoch. Sofern er das Häkchen, dass er das nicht möchte nicht ausschaltet. So kommen schnell genug immer aktuelle Daten zusammen.

Wie gesagt, offiziell darfst du das wegen Copyright nicht machen. Einfach rekompilierten Programmcode hochladen ist nicht erlaubt.

robbitop

2018-07-25, 12:23:38

Komische rechtliche Lage, wenn jeder per Emu den Code zur Laufzeit selbst erzeugen kann...
Ob ich den nun runterlade oder selbst erzeuge macht für Dritte und Rechteinhaber keinen Unterschied...

Ganon

2018-07-25, 12:26:32

Das hat natürlich in dem Fall noch kein Richter entschieden. Aber wenn du Emulator-Entwickler bist, dann willst du garantiert nicht die Anwälte von Nintendo, Sony oder MS auf der Matte haben. Alleine den Code zu veröffentlichen dürfte schon das Problem sein.

Wenn du deine Datenträger selbst rippst hast du auch kein Problem. Lädst du das Ergebnis noch, dann schon.

iuno

2018-07-25, 12:52:21

fuer cEMU gibt es akaik Shader Packs, wo man die kompilierten Shader runterladen kann. Steam denkt ja auch darueber nach, die lokalen shader caches bei den Nutzern direkt von der DB aus zu befuellen. Es wird also schon was gemacht in die Richtung.

Aber sollte nicht eigentlich bei Vulkan der Performance hit allgemein kleiner ausfallen, da der Shader ja schon als IR vorliegt statt im Quellcode? Da ist ein Teil der Arbeit ja schon gemacht.

Mich wundert es eher, dass bei Konsolen die Shader noch "normal" ausgeliefert werden und nicht vorkompiliert, ist schliesslich alles dieselbe Hardware. Oder stimmt das gar nicht und die Emus nehmen die vorkompilierten Shader wieder auseinander?

robbitop

2018-07-25, 13:00:42

Ich denke mal, dass die Shader neu kompiliert werden müssen, da es ja nicht auf der Original API und Original HW läuft.
Daran wird Vulkan in diesem Fall (Emu) wahrscheinlich nichts ändern können.

Wenn cEMU das tut und Valve über soetwas nachdenkt, macht das skeptisch was den Einwurf des potenziellen Rechtsverstoß angeht.

robbitop

2018-07-25, 13:05:21

Ggf ein alternativer Ansatz:
Es scheinen ja jetzt immer mehr Cores pro CPU in den Consumerbereich zu kommen (TR2 -> 32C, Zen2: 12-16C, SKL-X bis zu 18C etc)
Weiterhin scheint Shadercompiling parallelisierbar zu sein (sonst würde die Implementation per Compute auf der GPU wenig bringen - zumal man über PCIe Daten kopieren muss -> Laufzeit).

Anstatt das asynchron zu tun, könnte man ja eine ganze Menge CPU Threads dafür nutzen (z.B. bei einer 16C/32T CPU -> 8C/16T) um die Kompilierung so schnell wie möglich durchzuführen und den Anteil an der Renderzeit pro Frame verkürzen. Je mehr Leistung, desto kürzer der Anteil. Dann gäbe es keine Artefakte mehr.
Wäre ein Einsatzzweck der neuen Consumer Manycore CPUs.

aufkrawall

2018-07-25, 13:21:50

Was hat Shader-Kompilieren denn mit Compute zu tun? Und wenn das so einfach MTbar wäre, wäre das sicherlich schon in llvm drin.

Ganon

2018-07-25, 13:22:25

fuer cEMU gibt es akaik Shader Packs, wo man die kompilierten Shader runterladen kann.

Wie gesagt, das ist so gesehen nicht legal.

Steam denkt ja auch darueber nach, die lokalen shader caches bei den Nutzern direkt von der DB aus zu befuellen. Es wird also schon was gemacht in die Richtung.

Steam hat dir aber auch das ganze Spiel verkauft und weiß, dass du eine Nuztungslizenz hast. Das ist ganz was anderes als wenn zig Random Nutzer irgendwelches Copyright-behaftetes Material ins Internet blasen.

Mich wundert es eher, dass bei Konsolen die Shader noch "normal" ausgeliefert werden und nicht vorkompiliert, ist schliesslich alles dieselbe Hardware. Oder stimmt das gar nicht und die Emus nehmen die vorkompilierten Shader wieder auseinander?

Vollkommen egal. Du kannst weder den Playstation Shadercode noch dessen Bytecode einfach an deinen PC-Grafiktreiber schicken. Der kann damit nichts anfangen.

robbitop

2018-07-25, 13:38:21

Was hat Shader-Kompilieren denn mit Compute zu tun? Und wenn das so einfach MTbar wäre, wäre das sicherlich schon in llvm drin.
Der Emulator scheint das Kompilieren der Shader (online) statt auf der CPU per AC (asynchronous compute) auf die GPU zu schieben.

aufkrawall

2018-07-25, 13:46:04

Ich glaub eher, dass die CPU nicht mehr mit anderem Kram wartet, bis das Kompilieren fertig ist, und als Krücke betroffene Bereiche einfach so lange nicht dargestellt werden.

iuno

2018-07-25, 13:46:40

Vollkommen egal. Du kannst weder den Playstation Shadercode noch dessen Bytecode einfach an deinen PC-Grafiktreiber schicken. Der kann damit nichts anfangen.
Das ist schon klar, beantwortet die Frage aber nicht.
Der Emulator scheint das Kompilieren der Shader (online) statt auf der CPU per AC (asynchronous compute) auf die GPU zu schieben.
Das bezweifle ich mal stark. Wo hast du das denn her?

Zumal das Kompilieren der Shader ja sowieso Treiberaufgabe ist.

Ganon

2018-07-25, 13:57:10

Der Emulator scheint das Kompilieren der Shader (online) statt auf der CPU per AC (asynchronous compute) auf die GPU zu schieben.

Du verwechselst da was. Async Shader Compiler heißt, dass der Emulator einen Shader-Ladebefehl und sämtliche Drawcalls mit diesem Shader ignorieren kann, solange der Shader noch nicht verfügbar ist. Das hat nichts mit Async Compute zu tun.

Das ist schon klar, beantwortet die Frage aber nicht.

Naja, der Emulator muss dementsprechend den Shader auseinanderpflücken und neu zusammenbauen / neu schreiben, damit die PC-GPU was damit anfangen kann. Bei Dolphin verkürzt Vulkan die Compile-Zeit merklich, aber das behebt das Problem nicht. Ob das Spiel nun 5ms oder 10ms pausiert, ist da relativ egal :D

iuno

2018-07-25, 13:58:37

Aber werden sie denn nun im Original auf der PS binaer oder im Source Code ausgeliefert? :D
Dass uebersetzt werden muss, trifft ja auf beide Faelle zu.

aufkrawall

2018-07-25, 13:58:58

Bin mal gespannt, ob man das jemals generisch lösen können wird.

Ganon

2018-07-25, 14:06:48

Aber werden sie denn nun im Original auf der PS binaer oder im Source Code ausgeliefert? :D
Dass uebersetzt werden muss, trifft ja auf beide Faelle zu.

Das weiß ich nicht, ob alle Spiele Bytecode ausliefern...

Bin mal gespannt, ob man das jemals generisch lösen können wird.

Können ja, ist aber eine Frage der Rechenzeit. Dolphin z.B. hat einen "Ubershader", der die GC/Wii GPU per GPU Shader emuliert. Parallel emuliert die N64 "GPU" ebenfalls per Compute-Shader.

Die PS3 GPU ist halt wesentlich komplexer, womit das halt nicht so einfach machbar ist.

aufkrawall

2018-07-25, 14:17:19

Emulatoren interessieren mich weniger, ich dachte an DXVK.

robbitop

2018-07-25, 14:32:49

@compiler
Danke für die Info (aufkrawall, iuno, ganon) :)

Können ja, ist aber eine Frage der Rechenzeit. Dolphin z.B. hat einen "Ubershader", der die GC/Wii GPU per GPU Shader emuliert.
Das bedeutet dann, dass die Ubershader (durch die Emulation der ganzen GPU) dann den Code nativ ausführt, so dass eine Rekompilierung nicht notwendig ist?

Das für einen RSX auszuführen (bzw zu wollen) ist sicherlich nicht nur komplexer sondern sicherlich auch extrem leistungshungrig... (zumal IIRC wesentliche Teile der Beleuchtung auf den SPEs außerhalb der GPU liefen - wie auch backface culling IIRC)

Ganon

2018-07-25, 14:49:00

Das bedeutet dann, dass die Ubershader (durch die Emulation der ganzen GPU) dann den Code nativ ausführt, so dass eine Rekompilierung nicht notwendig ist?

"Code" ist für die Hardware aus der Generation vielleicht ein etwas weit gedehnter Begriff, aber ja. Der Shader versteht die vom Spiel durchgeführten Anweisungen an die GPU direkt und führt entsprechenden "PC-GPU-Code" aus.

Das für einen RSX auszuführen (bzw zu wollen) ist sicherlich nicht nur komplexer sondern sicherlich auch extrem leistungshungrig... (zumal IIRC wesentliche Teile der Beleuchtung auf den SPEs außerhalb der GPU liefen - wie auch backface culling IIRC)

Um das für die PS3 GPU zu machen, dürfte es aktuell an jeglicher Leistung fehlen. Letztendlich müsste der GPU-Shader den Bytecode ausführen können. Die SPE der CPU gehören natürlich ebenso mit dazu.

Da man aber schon bei Dolphin eine aktuelle GPU für die ganze Geschichte braucht, ist das mit einer PS3 GPU einfach noch in weiter ferne.

robbitop

2018-07-25, 15:09:45

Demirug

2018-07-25, 15:52:57

Emulatoren interessieren mich weniger, ich dachte an DXVK.

Was auch eine Art Emulator ist.

Wieso nicht "Code"? IIRC hatte die GC/Wii GPU immerhin schon Registercombiner, die vergleichbar mit den Pixelshadern in DX8.1 waren, oder? Zwar noch Integer und sehr begrenzt programmierbar - aber in die Richtung Pixelshader geht es schon. (wenn man die Pixelshader bei NV2x und R2xx als solche bezeichnet) :)

Die DX8.x Pixelshader waren eigentlich nicht viel mehr als eine schönere Art die Pixelpipeline zu konfigurieren. Bei DX7 musste man das mit vielen einzelnen APIs aufrufen. Man kann den kompletten Umfang der Wii GPU mit einem einzelnen Shader abdecken nur besteht der dann eben aus sehr vielen Verzweigungen was auf die Performances geht. Smart wäre es in solchen Fällen erst mal den Übershader zu nehmen und dann im Hintergrund optimierte zu erzeugen. Die nVidia Treiber bis DX11 können sowas in der Art auch. Der RSX ist nun aber schon so komplex das man seinen vollen Umfang nicht mehr mit einem einzigen Übershader vernüpftig realisieren kann.

Ganon

2018-07-25, 15:54:57

Wieso nicht "Code"? IIRC hatte die GC/Wii GPU immerhin schon Registercombiner, die vergleichbar mit den Pixelshadern in DX8.1 waren, oder? Zwar noch Integer und sehr begrenzt programmierbar - aber in die Richtung Pixelshader geht es schon. (wenn man die Pixelshader bei NV2x und R2xx als solche bezeichnet) :)

Ja, ich bin hier lieber vorsichtig mit allgemeinen Bezeichnungen. Die GC/Wii GPU hat halt "nur" HW T&L und wie du sagst HW mit ähnlichen Möglichkeiten wie Pixel Shader 1.0. Es ist aber immer noch ein Unterschied zwischen dem und "ich lade ein Programm in die GPU und schieb dem dann Informationen per Variablen rüber".

Aber da vorhin die Frage nach Vulkan-Vorteilen war. Die Konsolen wurden ja auch gerne in "Low Level" Manier programmiert. Entsprechend hauen die Konsolen gerne viele Drawcalls auf einmal raus und das beißt sich mit mit den High Level APIs. Hier z.B. ein Vergleich Twilight Princess OpenGL vs. Vulkan. 44 vs. 116 fps

https://de.dolphin-emu.org/blog/2018/07/21/myth-debugging-wii-more-demanding-emulate-gamecube/#a-look-at-the-numbers

Smart wäre es in solchen Fällen erst mal den Übershader zu nehmen und dann im Hintergrund optimierte zu erzeugen.

Dolphin kann das. Hybrid Mode nennen sie das.

edit:
allgemein vielleicht noch Infos dazu:

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

aufkrawall

2018-07-25, 16:16:11

Was auch eine Art Emulator ist.

Aber für eine wahrscheinlich viel stärker abstrahierte API für zig GPUs.
Niedrigere GPU-Leistung ist auch keine Option, weil man für die Spiele keine Ressourcen zu verschwenden hat.

danarcho

2018-07-25, 17:43:03

Was auch eine Art Emulator ist.

Nein, es ist kein Emulator und auch nichts in der Art. DXVK ist nur ein API-Layer von Dx11 nach Vulkan. Sämtlicher Code läuft nativ (der CPU game code sowie die GPU shader). Die shader werden dafür von hlsl bytecode nach SPIR-V übersetzt und dann an den Vulkan-Treiber weitergereicht.

Die Frage weiter oben, ob Bytecode Vorteile in der Compile-Geschwindigkeit hat. Nein, die mit Abstand größte Zeit verbringt der Shader-Compiler mit den optimization passes, und die sind praktisch gleich. Bei Radv zB sinds glaub 60% in LLVM, 30% in NIR und ein kleiner Rest mit eigentlichem Übersetzen.
Für DXVK wurde jetzt das nooptimization flag eingeführt, um die latency zu verbessern während im Hintergrund optimiert wird. Bringt aber nur ein bisschen was, weil bei LLVM leider viele Sachen nicht optional sind, wenn man funktionsfähige Shader erhalten möchte.

Stichwort kompilieren auf der GPU: ausgeschlossen, das ist vielleicht technisch möglich, aber nicht sinnvoll, da man eine hohe single threaded performance braucht und multithreading nur für mehrere shader sinnvoll ist.

Letzter Punkt, shader cache. Alle Treiber cachen selbst mittlerweile. Zusätzlich bietet steam unter Linux (beta?) einen shader cache, welcher vorab gefüllt werden kann. Dabei müssen aber GPU modell und Treiber Version (hier wird der timestamp verwendet, also auch nur je distro) übereinstimmen. steam lädt die shader selbstständig hoch und synchronisiert sie zwischen usern mit gleichem setup.
Emulatoren verbreiten keine shader genausowenig wie sie roms verbreiten. Btw, dort wäre es ja wohl viel klüger den x86 code zu teilen anstatt gpu und Treiber abhängige shader...

aufkrawall

2018-07-25, 18:08:45

Steam hat mir über diese Funktion leider noch nie auch nur einen einzigen kompilierten Shader geladen, auch mit stabilen Versionen von Mesa und llvm nicht.

Demirug

2018-07-25, 18:16:17

Nein, es ist kein Emulator und auch nichts in der Art.

Definitionssache.

Es emuliert unvollständig eine Softwareschnittstelle welche es auf dem Hostsystem nicht gibt. Gerade die Tatsache das der Shadercode von einem Instructionset in ein anderes übersetzt wird ist ein typische Merkmal einer Highlevel Emulation.

Wenn man damit auch original DX12 Treiber verwenden könnte wäre das was anderes. Dann hätten wir es mit einer alternativen Implementierung zu tun.

Exxtreme

2018-07-25, 19:02:59

Nein, es ist kein Emulator und auch nichts in der Art. DXVK ist nur ein API-Layer von Dx11 nach Vulkan. Sämtlicher Code läuft nativ (der CPU game code sowie die GPU shader). Die shader werden dafür von hlsl bytecode nach SPIR-V übersetzt und dann an den Vulkan-Treiber weitergereicht.

Wird wahrscheinlich ordentlich auf die CPU hauen so eine Echtzeitübersetzung der Shader. Ich kenne das von WoW weil ich einen D3D -> OpenGL-Umsetzer ab und zu nutze. Da verliert man rund 50 - 70% an Leistung.

aufkrawall

2018-07-25, 19:09:10

Nein, das kann man so pauschal nicht veranschlagen. Während des Kompilierens freezt das Rendering komplett. Auf die avg-fps hat das nach etwas Einlaufzeit kaum einen Effekt, der CPU-Overhead von DXVK ist ansonsten sehr gering (hatte hier vor Kurzem dazu Screenshots gepostet).

danarcho

2018-07-25, 19:25:00

Definitionssache.

Es emuliert unvollständig eine Softwareschnittstelle welche es auf dem Hostsystem nicht gibt. Gerade die Tatsache das der Shadercode von einem Instructionset in ein anderes übersetzt wird ist ein typische Merkmal einer Highlevel Emulation.

Wenn man damit auch original DX12 Treiber verwenden könnte wäre das was anderes. Dann hätten wir es mit einer alternativen Implementierung zu tun.

Dann wäre jede library und jeder Treiber ein Emulator. Denn sie bieten Schnittstellen an, die es sonst auf dem Host nicht gibt?!
Auch übersetzt jeder Treiber die Shader, (um sie auf der Gpu auszuführen). Diese Definition ist totaler nonsense, dann könnte man Vulkan treiber auch als SPIR-V emulatoren bezeichnen, da der host ja SPIR-V nicht nativ ausführen kann. oder die jre als java-emulator. wtf

Was die Performance angeht, die Zeit die es braucht zum Kompilieren (oder bei dxvk erst transpilieren zu spir-v) hat keinerlei Einfluss auf die Performance außer ein paar mikrorucklern anfangs. Die Frames unter dxvk erreichen doch knapp die windows performance? wenns deutlich drunter ist, liegt das meist eher am vulkan treiber.

aufkrawall

2018-07-25, 19:32:44

Was die Performance angeht, die Zeit die es braucht zum Kompilieren (oder bei dxvk erst transpilieren zu spir-v) hat keinerlei Einfluss auf die Performance außer ein paar mikrorucklern anfangs.

Das ist wirklich sehr untertrieben. Es freezt wie die Pest, und bei neuen Shadern (z.B. komplett anderer Level) auch nach Stunden noch.

Die Frames unter dxvk erreichen doch knapp die windows performance? wenns deutlich drunter ist, liegt das meist eher am vulkan treiber.
Müsste man wohl mit AMD unter Windows testen, ich hab hier in letzter Zeit zur Genüge meine Horror-Erfahrungen mit dem Nvidia-Vulkantreiber gepostet. :frown:

danarcho

2018-07-25, 19:50:48

Steam hat mir über diese Funktion leider noch nie auch nur einen einzigen kompilierten Shader geladen, auch mit stabilen Versionen von Mesa und llvm nicht.
Wie gesagt wird imho der timestamp des treibers verwendet, was bedeutet, dass wenn du ihn selbst baust, du auch der einzige Nutzer von dieser "Version" sein dürftest. Ansonsten kannst du mir gerne OS, GPU und Treiber nennen und ich frag mal nach. (Bin mir gerade bei den NV Treibern nicht sicher ob es ein Problem sein könnte wenn die von hand installiert werden).
Die starken Ruckler sind zumindest ein Problem dessen man sich bewusst ist.

=Floi=

2018-07-26, 04:54:03

Die starken Ruckler sind zumindest ein Problem dessen man sich bewusst ist.

warum gelangt so etwas dann an die öffentlichkeit und an den endverbraucher?
Dort sollten ja eigentlich fachkräfte sitzen welcher sich solcher probleme bewusst sein müssten. :rolleyes:
Warum wirt so etwas zu laufzeit compiliert?

Auch hier frage ich mich, ob die ihre games nicht selbst zocken?!

gravitationsfeld

2018-07-26, 05:00:53

"Ihre" games? Es geht um dxvk.

Ganon

2018-07-26, 08:51:26

Hab mich mal informiert :D Letztendlich sagt der Entwickler von DXVK es hier (https://github.com/doitsujin/dxvk/issues/168#issuecomment-373876061) und hier (https://github.com/doitsujin/dxvk/issues/464#issuecomment-401289340)

Wenn das Spiel CreateShader aufruft, dann macht DXVK die DXBC -> SPIR-V Umwandlung. Unter DX11 ist es aber nun wohl so, dass man jetzt die Shader fröhlich nutzen und kombinieren kann wie man will, ohne, dass man sonderlich was davon merkt. Unter Vulkan muss aber zuerst eine Vulkan Pipeline eingerichtet werden und das ist teuer. Man kann auch nicht "vorab" sagen wie und welche Shader benutz werden.

Letztendlich auf der DXVK Seite nicht fixbar. Ein Patch für Async Shader (https://github.com/jomihaka/dxvk-poe-hack) gibt's aber wohl auch. Das Spiel müsste eine "warmup Phase" einbauen indem alle Shader vorher mal kurz benutzt werden.

Fragt sich ob Wine mit ihrem DX11 -> OGL die gleichen Probleme hat, oder ob es da ebenso "günstig" ist.

aufkrawall

2018-07-26, 11:56:47

Wine OGL ist ebenso betroffen.

danarcho

2018-07-26, 15:47:22

Philip Rebohle hat dxvk afaik während seines Bachelors in der Freizeit angefangen (jetzt Vollzeit). Und radv ist ebenfalls ein open-source projekt. Es liegt nun mal in der Natur der open-source Projekte, dass man die gesamte Entwicklung inklusiver aller Schwierigkeiten und Fehler mitbekommt. Es ist doch eher absolut vorbildlich von Valve diese Projekte zu unterstützen.

aufkrawall

2018-07-26, 16:00:46

Es hat doch niemand dxvk oder radv kritisiert?
doitsujin steht in gutem Kontakt zu den Treiber-Entwicklern, durch das Projekt wurden schon diverse Treiber-Bugs gefixt. Meine Hoffnung wär ja, dass dadurch der llvm-Compiler schneller entsprechend umgebaut wird.

danarcho

2018-07-26, 17:33:26

Floi, aber egal.
Meine Hoffnung wär ja, dass dadurch der llvm-Compiler schneller entsprechend umgebaut wird.
Zu was soll der umgebaut werden? Magst du deine Hoffnungen ein bisschen ausführen? LLVM ist eine ziemlich große Baustelle, an der momentan hauptsächlich die eigenen Leute von AMD sitzen. Schnelle Verbesserungen würde ich an der Front aber nicht erwarten.

Ich habe mal wegen des steam shader cache nachgefragt. Bei nv wird die treiber-version als hash genommen (also nicht der timestamp), du kannst nicht direkt nachsehen, welche shader darüber geladen wurden. aber du kannst (nach beenden des spiels) in der shader_log.txt sehen wie viele shader kompiliert werden mussten.

aufkrawall

2018-07-26, 17:58:03

Im Options-Menü verrät Steam einem, ob irgendwelche Shader pregecacht sind, und dort steht ausnahmslos immer "0MB" bei mir.
Zu llvm: Ich habe ja nicht gesagt, dass ich auf eine baldige Besserung hoffe. Wenn es in 2-3 Jahren deutlich besser läuft als jetzt, wär das auch schon etwas.

gravitationsfeld

2018-07-26, 21:25:30

Was hat das eigentlich mit Vulkan zu tun?

Kriton

2018-07-28, 11:22:27

Nein, es ist kein Emulator und auch nichts in der Art. DXVK ist nur ein API-Layer von Dx11 nach Vulkan. Sämtlicher Code läuft nativ (der CPU game code sowie die GPU shader). Die shader werden dafür von hlsl bytecode nach SPIR-V übersetzt und dann an den Vulkan-Treiber weitergereicht.

Das mit den Shadern klingt ähnlich, wie das was ich früher (keine Ahnung, ob das heute auch noch gilt) einen Interpreter genannt hätte (man denke an C64 und Basic V2 im Verhältnis zu dem Maschinencode). Oder verstehe ich das falsch?

danarcho

2018-07-28, 11:58:54

Hm, nein. Ein (klassischer) Interpreter evaluiert den Quellcode Zeile für Zeile und übersetzt quasi immer nur den Teil des Programms, der auch ausgeführt wird. Die Shader werden aber (egal unter welcher API) immer als ganzes in GPU binaries (Maschinencode) übersetzt. AMD hat zB das instruction set für die verschiedenen GPU Generationen auch schöne online dokumentiert (einfach mal GCN ISA googlen), falls dich interessiert wie GPU assembly so aussieht.

Kriton

2018-07-28, 12:04:29

Danke für die Erklärung.

aufkrawall

2018-08-07, 19:37:27

N0Thing

2018-08-08, 01:40:47

Vermutlich, weil konträr zur Ansicht der Forentrollen, doch viel Arbeit seitens Bethesda Softworks, in den Nvidia-Teil geflossen ist.

aufkrawall

2018-08-16, 18:29:15

Passt nicht zu 100% hier rein, aber so halbwegs:
https://www.gamingonlinux.com/articles/valve-may-be-adding-support-for-using-compatibility-tools-for-playing-games-on-different-operating-systems.12349
Ich sag mal noch dazu, dass es das Gerücht gibt, dass der DXVK-Entwickler von Valve bezahlt wird. ;)
/spekuspeku

gravitationsfeld

2018-08-17, 04:10:42

Find ich super. Vulkan-Spiele laufen dann wohl wirklich ohne weiteres in Steam/Linux. Praktisch (fast) so gut wie ein nativer Port.

Ich frage mich ob das auch mit solchen Geschichten wie Denuvo geht?

Ganon

2018-08-17, 09:25:41

Ich frage mich ob das auch mit solchen Geschichten wie Denuvo geht?

Soweit ich weiß funktioniert Denuvo prinzipiell in WINE. Es hängt halt hauptsächlich davon ab, was für Windows APIs das alles triggert und was davon noch nicht implementiert ist.

Nur auf Kernel/Treiber-Ebene wird's dann eklig (StarForce und Co.). Nicht unmöglich, aber schwierig.

Troyan

2018-08-17, 23:23:17

Aus dem Resetera Forum - Final Fantasy 15 bekommt Vulkan?!
https://steamdb.info/app/637650/config/

aufkrawall

2018-08-21, 12:15:32

Find ich super. Vulkan-Spiele laufen dann wohl wirklich ohne weiteres in Steam/Linux. Praktisch (fast) so gut wie ein nativer Port.

Jup. Nur wie läuft das eigentlich mit dem Input bei Vulkan-Spielen? Bei DirectX-Spielen gibts mit Wine leider relativ häufig Probleme wie spinnender Maus-Input. Aber Wine in Steam dürfte immerhin für einiges Polishing dahingehend sorgen.

Demirug

2018-08-21, 13:38:00

Jup. Nur wie läuft das eigentlich mit dem Input bei Vulkan-Spielen? Bei DirectX-Spielen gibts mit Wine leider relativ häufig Probleme wie spinnender Maus-Input. Aber Wine in Steam dürfte immerhin für einiges Polishing dahingehend sorgen.

Mit einer der entsprechenden APIs welche das jeweilige OS dafür hat. Bei Windows hat man da die gleiche Auswahl wie bei einem DirectX Spiel.

gravitationsfeld

2018-08-21, 16:23:41

Auch andere haben miese Performance mit Nvidia und DXVK festgestellt:
https://github.com/doitsujin/dxvk/issues/267#issuecomment-410441124
radv ist meist durchweg deutlich schneller. :freak:

Ich hatte übrigens kurz wieder die RX 560 drin und die Probleme mit mpv und Nvidia (Crash unter Windows durch Resizen, hohe CPU-Last unter Linux) waren definitiv weg.
Wie können Doom und Wolfenstein überhaupt mit Nvidia laufen...
Ich sag mal so, die NVidia-Seite macht auf jeden Fall viel mehr Zicken. Das liegt aber auch an komischen Eigenschaften ihrer Hardware.

Jup. Nur wie läuft das eigentlich mit dem Input bei Vulkan-Spielen? Bei DirectX-Spielen gibts mit Wine leider relativ häufig Probleme wie spinnender Maus-Input. Aber Wine in Steam dürfte immerhin für einiges Polishing dahingehend sorgen.
Vulkan ist eine reine Grafik-API. Komische Frage.

Ganon

2018-08-22, 00:05:58

Ich sag mal noch dazu, dass es das Gerücht gibt, dass der DXVK-Entwickler von Valve bezahlt wird. ;)
/spekuspeku

Ist nun quasi offiziell. Valve mischt jetzt (oder eher schon lange) bei WINE, DXVK (DX10 & DX11) und VKD3D (DX12) mit. Die Steam Beta unterstützt einige Spiele nun damit offiziell.

https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561

iuno

2018-08-22, 01:02:05

Screemer

2018-08-22, 01:09:28

Ziemlich cool.

Ganon

2018-08-22, 08:51:09

Schoen, dass Valve solche Leute unterstuetzt. Kurzfristig sicher auch nett fuer Wine-Spieler. Aber ob das laengerfristig so hilfreich ist? Da werden devs, die vielleicht eine native Version gebracht haetten, moeglicherweise zukuenftig wieder drauf verzichten.

Ist fraglich, aber die Indies, die Unity und Co. verwenden kriegen eine Linux-Version quasi mit einem Klick. Das werden die sicherlich auch weiterhin tun. AAA Spiele mit Linux Support kannst du an der Hand abzählen und davon läuft die Hälfte beschissen :D

Ich mein, schaue dir die Liste mal ganz genau an. Da findest du DOOM 2. Ja, DOOM 2, was in einer DOSBOX ausgeliefert wird. Der Hersteller war also nicht mal gewillt einfach eine einzelne Binary auszutauschen die es quasi überall gibt :ugly:

Ich sehe es als Chance, dass doch mehr Leute vielleicht mal einen Blick über den Tellerrand werfen. Mit einem Steam Marktanteil von <1% wirst du halt sonst niemanden bewegen. Und laut dem hier (https://www.gamingonlinux.com/articles/valve-officially-confirm-a-new-version-of-steam-play-which-includes-a-modified-version-of-wine.12400) gilt ein Verkauf als Linux-Sale wenn du das Spiel nach 2 Wochen länger unter Linux/Proton gespielt hast.

Aber die Diskussion führen wir vielleicht lieber im Linux-Forum weiter :D

Mal wieder On-Topic:

Schön zu sehen, dass Steam jetzt quasi mal halbwegs darum bittet Vulkan zu unterstützten. Ich rechne zwar nicht damit, dass das viele zum Umdenken verleitet, aber man weiß ja nie.

iuno

2018-08-22, 09:55:12

Ist fraglich, aber die Indies, die Unity und Co. verwenden kriegen eine Linux-Version quasi mit einem Klick.
Ja, vorausgesetzt sie haben keinen plattformabhaengigen 3rd-party Code ins Projekt gezogen (oder selbst geschrieben) :freak:

OK, vielleicht hilft es auch in den Faellen wo die Entwickler bisher gar nicht an eine Linux-Version gedacht haben. Die koennten jetzt doch mal schauen ob der Titel dann mit Proton laeuft, was ja auch etwas einfacher ist als von Hand WINE usw. einzurichten.

Auch interessant finde ich uebrigens, dass Valve AMDVLK fuer genauso relevant haelt wie ich. :P Die installieren/empfehlen natuerlich nur noch die Mesa Treiber.

Troyan

2018-08-23, 00:16:14

Enlisted mit Vulkan und Raytracing: https://www.youtube.com/watch?v=ZnQRzLZ5nEE

Unicous

2018-08-24, 16:17:35

AMDs Vulkan "Easy Mode" Wrapper ist jetzt Open Source:

https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ

Locuza

2018-08-27, 10:14:56

Ich weiß nicht ob es schon bekannt war, aber Strange Brigade, ein Spiel von Rebellion welche Sniper Elite entwickelt haben und mitunter die einzige gute DX12-Umsetzung implementiert, wo selbst Nvidia mit DX12 im GPU-Limit Performance gewinnt, setzt (auch?) auf Vulkan:
- Minor corruption may be observed when launching Strange Brigade™ with Vulkan™ enabled on Windows®7 system configurations.
- An application hang may occur in Strange Brigade™ on multi GPU enabled systems with both V-Sync enabled in game and Radeon FreeSync enabled on Windows®7 operating system.
- Radeon Overlay may not show up when toggled in multi GPU system configurations in Strange Brigade™ with Vulkan™ enabled.
https://videocardz.com/driver/amd-radeon-adrenalin-edition-18-8-2-beta

Leider interessieren mich deren Spiele persönlich gar nicht, aber es ist schön zu sehen wie Vulkan indem Fall nachträglich Support erfährt, trotz DX11 und DX12 Backend.

dargo

2018-08-27, 10:33:00

Ja... gibt DX12 und Vulkan.
https://www.techspot.com/article/1685-strange-brigade-benchmarks/

Locuza

2018-08-27, 11:00:09

Klasse Link. :up:
Wenn ich das richtig sehe dann gibt es gar kein DX11 mehr.
Der Async Compute Gewinn unter den Radeons und Geforce GPUs spiegelt die Ergebnisse von damals bei Sniper Elite 4 bei Computerbase wider.
Vulkan läuft aber relativ mies bei den Geforce Ablegern, AMD verliert 2-5%, Nvidia dagegen 8-14%.

Ich bin gespannt woran das liegt, beim GFX-Bench 5.0 hat sich die Vulkan-Implementierung gegenüber DX12 als 8% schneller auf einer 1070 erwiesen:
https://www.computerbase.de/2018-08/gfxbench-5.0-benchmark-aztec-ruins-vulkan-metal-directx-12/

dildo4u

2018-08-27, 11:06:26

NVs Gameready Treiber ist noch nicht raus,ich hoffe mal PCGH macht Vulkan Benches wenn es einen gibt.

dargo

2018-08-27, 11:16:27

Wenn ich das richtig sehe dann gibt es gar kein DX11 mehr.

Bin mir nicht sicher, würde aber darauf tippen. Kein DX11 würde ich auch begrüßen, so können sich die Entwickler mehr auf low level konzentrieren. Die Win7 User haben ja Vulkan. Win10 User haben DX12 und Vulkan zur Auswahl. So bedient man optimal alle Spieler.

Der Async Compute Gewinn unter den Radeons und Geforce GPUs spiegelt die Ergebnisse von damals bei Sniper Elite 4 bei Computerbase wider.
Vulkan läuft aber relativ mies bei den Geforce Ablegern, AMD verliert 2-5%, Nvidia dagegen 8-14%.

Ich tippe mal darauf, dass das ganze noch relativ Beta ist (der intergrierte Benchmark soll bsw. stottern). Mal sehen was noch zukünftige Patches/Treiber bringen.

gravitationsfeld

2018-08-27, 18:31:04

Bin mir nicht sicher, würde aber darauf tippen. Kein DX11 würde ich auch begrüßen, so können sich die Entwickler mehr auf low level konzentrieren. Die Win7 User haben ja Vulkan. Win10 User haben DX12 und Vulkan zur Auswahl. So bedient man optimal alle Spieler.
Warum sollte man DX12 ueberhaupt implementieren, wenn man schon einen Vulkan-Pfad hat? Angst vor nicht installierten Treibern?

dargo

2018-08-27, 19:06:08

Jetzt wo du es sagst. :freak: Keine Ahnung... vielleicht experimentieren die mit Vulkan gerade. DX12 kennen sie ja schon vom Vorgänger.

gravitationsfeld

2018-08-27, 20:07:35

DX12 kennen sie ja schon vom Vorgänger.
Was? DX12 hat so gut wie nichts mit DX11 zu tun.

dargo

2018-08-27, 20:11:03

Strange Brigade kommt von Rebellion. Vor dem Spiel lieferte Rebellion Sniper Elite 4 mit DX12.
https://www.computerbase.de/2017-02/sniper-elite-4-benchmark/

Screemer

2018-08-27, 20:11:56

Was? DX12 hat so gut wie nichts mit DX11 zu tun.
Er meint Sniper Elite 4. Die engine hatte schon nen dx12 renderer.

gravitationsfeld

2018-08-27, 20:42:21

Ah, verstehe.

Raff

2018-08-28, 10:49:49

Das Spiel läuft auch mit DX11(_0)-GPUs, auch wenn alles suggeriert, dass das nicht so ist.

MfG,
Raff

Ludi

2018-08-28, 19:42:42

Kann das jemand bestätigen? Wie sind da die Frame-Times?

Anyone else confirm Vulkan Multi-GPU working? I have two GTX 1080Ti's in SLI with a resolution of 7680x1440P @ 144hz. According to MSI Afterburner both my GPU's are showing 100% usage and getting 110+FPS at Ultra settings, no AA, Tesselation off.

https://steamcommunity.com/app/312670/discussions/0/1736588252417164005/

Raff

2018-08-29, 10:22:30

NVs Gameready Treiber ist noch nicht raus,ich hoffe mal PCGH macht Vulkan Benches wenn es einen gibt.

Strange Brigade im Benchmark-Test: Hochoptimierter Koop-Shooter mit Vulkan UND DirectX 12 (http://www.pcgameshardware.de/Strange-Brigade-Spiel-61029/Specials/Benchmark-Test-Review-1263803/) :naughty:

Unfassbar, wie gut das Spiel läuft.

MfG,
Raff

dildo4u

2018-08-29, 10:48:56

Die Werte sehen aus wie es sein sollte wenn eine 7850 in der PS4 1080p/30 darstellt.Natürlich muss man abwarten was Ultra beim PC gegenüber Konsole bringt.

Scheint zumindest sauber zu laufen auch wenn ein paar Prozent Performance fehlen.

3ART3yKLKm4

Ganon

2018-09-04, 09:46:50

Man diskutiert bei Khronos auf Nachfrage (https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/26) wohl intern, ob man Vulkan nicht um Transform Feedback erweitert. Das wurde u.a. damals bei der Spezifikation ausgelassen. Haupteinsatzzweck ist hier der DX11 -> Vulkan Wrapper DXVK, weil es aktuell nicht (performant) möglich ist das komplette DX11 auf Vulkan abzubilden. Betroffen (https://github.com/doitsujin/dxvk/issues/135) sind viele Unity- und einzelne eigenständige Spiele, darunter auch Witcher 3, Overwatch und alles mit NVidia Hairworks.

Die Diskussion geht da zwar schon lange, aber das Label "resolving inside Khronos" klebt da erst seit 11 Tagen dran :)

gravitationsfeld

2018-09-04, 14:01:00

Oh Gott, bitte nicht. Das ist ein Anti-Low-Level-Feature, das nicht in die Spec gehört. Man kann Buffer schreiben aus jeder Stage.

Ganon

2018-09-04, 14:22:18

Oh Gott, bitte nicht. Das ist ein Anti-Low-Level-Feature, das nicht in die Spec gehört. Man kann Buffer schreiben aus jeder Stage.

Sorry, meinerseits falsch ausgedrückt. Es muss nicht zwangsläufig 1:1 das Feature werden, aber Dinge, die dabei helfen es halbwegs performant nachzubauen. Aktuell scheint das nicht möglich zu sein. Könnte ja auch in einer optionalen Extension landen. Hauptproblem scheint wohl zu sein, dass Vulkan an einigen Stellen keine Garantien für die Reihenfolge gibt.

Wäre halt schade, wenn das Problem hier keine Lösung findet, da es ohne (sinnvolle) Lösung in zahlreichen Spielen zu Fehldarstellungen führt.

gravitationsfeld

2018-09-04, 14:30:25

Wäre schade, wenn man wegen der 0.01% and Leuten die an Linux-D3D-Emulation interessiert sind die Spec verwässert.

Ganon

2018-09-04, 14:49:17

Wäre schade, wenn man wegen der 0.01% and Leuten die an Linux-D3D-Emulation interessiert sind die Spec verwässert.

Naja. Die 5 Vulkan-Spiele für den PC, die die nächsten 10 Jahre noch auf den Markt kommen, wird's sicherlich nicht umbringen. ;)

Man weiß ja noch gar nicht was das am Ende wird, oder ob es überhaupt was wird. Ich hab aber lieber eine API, die man auch als Endanwender sinnvoll "benutzen" kann, als einen schönen Papiertiger.

aufkrawall

2018-09-04, 15:33:43

Wäre schade, wenn man wegen der 0.01% and Leuten die an Linux-D3D-Emulation interessiert sind die Spec verwässert.
Dieser Prozentwert entspricht wohl auch dem Anteil an Entwicklern, die unter Windows an Vulkan interessiert sind.

Unicous

2018-09-04, 15:58:28

Dieser Prozentwert entspricht wohl auch dem Anteil an Entwicklern, die unter Windows an Vulkan interessiert sind.

Aua.:eek:

Ganon

2018-09-04, 16:15:13

Auch mal so allgemein. Vulkan Multi-Plattform? Haha, guter Witz:
Windows@ARM: kein Support
macOS: kein Support
iOS: kein Support
XBOX Ökosystem: kein Support
Playstation Ökosystem: kein Support (mag sich mit der PS5 ändern, wer weiß)

Und ja, mir ist MoltenVK bekannt. Nutzt das irgendwer außer Valve für ihren DX9->Vulkan->Metal Pfad? Ich höre in Sachen Qualität eher so was im Bereich von "örks" bis "so lala". Ein paar Indie-Studios scheinen es zu benutzen. Im AAA-Bereich... niemand sonst? Na gut, woher auch.

Das "Vulkan-Ökosystem":
Windows@x86: Support über Dritthersteller, First-Class Support Alternative DX12 vorhanden
Android: wenn man Android 7 als Minimum voraussetzen will...
Linux: First-Class Support
Nintendo Switch: First-Class Support

Auch die in Teilen recht beliebte Rendering-Bibliothek "bgfx" hat Support für DX12 und Metal... aber kein Vulkan bisher. :ugly:

Zu den Treibern: "Oh man".
- NVidia zerlegt alle Nase lang ihre Vulkan-Implementierung
- AMDVLK ist ebenso buggy, wenn man nicht die per-game-basis Workarounds triggert (z.B. startete Rise of the Tomb Raider am Day-One gar nicht erst)
- radv braucht quasi immer den aktuellen -git master für aktuelle Vulkan-Software und Grafikkarten
- Intel hat keine Hardware bei denen Vulkan irgendwas bringen würde, Windows Support erst ab Skylake, anders als DX12

Klar, DX12 hat eine wesentlich geringere Adaption, wenn man diesen blöden Linux Pöbel mit reinrechnet, darum findet man auch "öffentlich" mehr Bugs.

Zum Spielesupport? Nunja, genauso mies wie DX12. Und die AAA Vulkan-Spiele sind sogar gerne Windows-Only. Strange Brigade unterstützt Vulkan? Schön! Erste Benchmarks sagen es ist minimal langsamer als DX12. Uuuuund Tschüss liebe Nutzer die das sonst benutzen würden.

Vielleicht bin ich ja auch weiterhin viel zu pessimistisch, aber ich sehe auch weiterhin keinen Durchbruch von Vulkan in Zukunft. Von daher bin ich eben der Meinung man sollte Vulkan dafür optimieren für das es auch im echten Leben benutzt wird. Man kann natürlich auch weiterhin von einer großen Vulkan-Zukunft im PC-Spielesektor träumen... Vielleicht Android, wenn "Android 7 und aufwärts" mal die 50% Marktanteil überschreitet.

Lurtz

2018-09-04, 16:39:37

Warum arbeiten Mozilla und Google an einem Vulkan-Backend für Firefox und Chrome?

Ganon

2018-09-04, 16:52:45

Warum arbeiten Mozilla und Google an einem Vulkan-Backend für Firefox und Chrome?

Auch wenn hier eher der große Kontext "Spiele" ist, gilt es für Anwendungen ähnlich:

https://skia.org/user/special/vulkan

Skia has a Vulkan implementation of its GPU backend. The Vulkan backend can be built alongside the OpenGL backend. The client can select between the OpenGL and Vulkan implementation at runtime. The Vulkan backend has reached feature parity with the OpenGL backend. At this time we find that many Vulkan drivers have bugs that Skia triggers for which we have no workaround. We are reporting bugs to vendors as we find them.

Auch bisher und weiterhin nichts was "per default" eingeschaltet ist und an Millionen Nutzer verteilt wird.

Dino-Fossil

2018-09-04, 16:56:58

Ist aber auch ein klassisches Henne-Ei-Problem.

Solange es kaum einer nutzt, werden die Treiber vernachlässigt, und wenn die Treiber nicht gut sind werden Entwickler davon abgehalten es zu nutzen...

Man kann jedenfalls nur hoffen, dass nicht alle die pessimistische Einstellung bzgl. Vulkan teilen, die hier einige haben... :wink:

aufkrawall

2018-09-04, 17:06:55

Warum arbeiten Mozilla und Google an einem Vulkan-Backend für Firefox und Chrome?
Die setzen ja ähnlich wie mpv intern auf eine abstrahierte API, um viele Backends (wie eben auch Vulkan) unterstützen zu können.
Obligatorischer Vulkan-Support wird halt auch für Android kommen. Klar, dass man das unterstützen muss.

Die Situation auf dem PC ist halt eine andere. Bisher ist Vulkan im Grunde nicht einmal für Android wichtig, sondern eigentlich nur Linux, und da wegen besserer OGL-Treiber eigentlich auch nur für DXVK/Windows-Ports.

gravitationsfeld

2018-09-04, 19:11:25

Dieser Prozentwert entspricht wohl auch dem Anteil an Entwicklern, die unter Windows an Vulkan interessiert sind.
Haha, lustig. Aber nein.

Naja. Die 5 Vulkan-Spiele für den PC, die die nächsten 10 Jahre noch auf den Markt kommen, wird's sicherlich nicht umbringen. ;)
Ihr werdet euch noch wundern. Abgesehen davon ist das irrelevant. Die API braucht man nicht mit Muell vollklatschen nur damit paar Linux-Hippies sich kein Windows installieren muessen. Das Zeug muss alles langfristig gewartet werden und hat Seiteneffekte.

Ganon

2018-09-04, 19:44:33

Ihr werdet euch noch wundern. Abgesehen davon ist das irrelevant. Die API braucht man nicht mit Muell vollklatschen nur damit paar Linux-Hippies sich kein Windows installieren muessen. Das Zeug muss alles langfristig gewartet werden und hat Seiteneffekte.

Och du, wenn sich das doch noch alles ändern sollte, hab ich auch absolut gar kein Problem damit. Win-Win for me, yay.

Aber mal ernsthaft. Ich kann mich auf nichts beziehen was ich nirgendwo belegen kann. Vielleicht macht Sony Vulkan auf der PS5 die #1 API, vielleicht nicht. Vielleicht unterstützen sie es als Zweit-API, vielleicht auch nicht...

An sich steht trotzdem noch die Frage im Raum, wozu man bei einem AAA-Spiel Vulkan nutzen sollte, wenn die "paar Linux-Hippies" eh nicht zählen. Ich mein, selbst Spiele wo ein Port zu macOS und Linux quasi eine klare Sache waren haben DX12 genommen (z.B. Civ 6 und Rise of the Tomb Raider).
macOS per MoltenVK? Android? Oder doch einfach alle auf Unity und Unreal Engine umsteigen und "ach API SchmAPI"?

Oder legst du aktuell nur all deine Hoffnungen in Android und vielleicht MoltenVK bzw. Portable Vulkan allgemein?

gravitationsfeld

2018-09-04, 20:56:29

An sich steht trotzdem noch die Frage im Raum, wozu man bei einem AAA-Spiel Vulkan nutzen sollte, wenn die "paar Linux-Hippies" eh nicht zählen.
Weil's die bessere API ist.

pixeljetstream

2018-09-04, 22:09:40

+1 :)
Wenn HLSL Dominanz nicht wäre ;) aber die spriv toolchain wird da ja auch besser.

Raytracing kommt nicht zu GL, nur zu Vulkan, das wird auch die Industrie langsam bewegen.
Die Migration mag langsam sein, aber letztlich haben die meisten IHVs Interesse Geld zu sparen und sich auf VK zu konzentrieren.
Und viele ISVs wollen am Ende auch das threading Modell und bissl mehr Kontrolle.
Langfristig wenn es in die Cloud geht, haben auch alle ein Interesse sich MS Lizenzen zu sparen.

Das Hauptproblem am xfb ist der primitive-ordered append während man zeichnet, den kriegt man nicht so trivial flott emuliert, brauchst nen compaction pass. Aber stimme zu, das sollte draussen bleiben. Am Ende emulieren die eh schon nen Schwung dann müssen sie halt nen Code Generator dafür bauen.

Ganon

2018-09-04, 23:50:22

Es geht ja auch gar nicht um eine Kritik an der API selbst. Auch nicht um ihren Einsatz generell. Bei Cross-Platform-Anwendungen aller Art wird Vulkan natürlich über kurz oder lang OpenGL ersetzen, keine Frage. Hier reden wir aber vermutlich von einem Zeitraum von bis zu 10 Jahren. Vulkan selbst ist ja schon über 2.5 Jahre alt. Aber anders gefragt: Wird Vulkan eurer Meinung nach wirklich DX12 inkl. seiner Addons (Raytracing) ersetzen? Also in der Praxis, nicht nur in der Theorie.

Jetzt mal rein auf den Spielesektor bezogen... alles was nicht gerade sowieso wahlweise Multi-API ist so wie Unity... wann ca. meint ihr wird es denn "kippen", sodass die eigenen Engines von anderen Entwicklern unter Windows nicht an DX12 kleben und zumindest eine Vulkan-Option bieten? Oder hat Strange Brigade jetzt den neuen "Standard" eingeläutet? Also es ist ja z.B. nett, dass die Frostbite Engine intern Vulkan unterstützt, bringt mir dann aber wiederum nichts, wenn sie das unter Windows nicht wahlweise mitliefern. Auch Assassins Creed Odyssey wird ja soweit ich weiß ein DX12-Titel. Und warum hat Blizzard eigentlich auch DX12 gewählt für WoW?

Unter Unity kann man ja mittels Startparameter zwischen OpenGL und D3D wechseln. Meint ihr vielleicht der Weg wird mehr unterstützt? Lief bei Unity aber ja auch eher so lala, wenn der Entwickler da nicht mal drüber geschaut hat. Hab z.B. einige Grafikfehler in Subnautica wenn ich OpenGL erzwinge.

Also die Adaption in den zahlreichen Engines selbst mag ja vielleicht da sein, ich würde das aber lieber auch beim Endanwender selbst sehen.

gravitationsfeld

2018-09-05, 00:34:45

Es gibt viel FUD was das angeht in der Industrie.

pixeljetstream

2018-09-05, 07:54:06

Vulkan wird imo immer das Problem haben hinter DX zu sein was die Standardisierung angeht (Demokratie ist langsam). Das macht DX bei AAA attraktiver. Daneben noch die Qualitätssicherung, Tools, Marketing das MS bezahlt.
Für VK gibt es Valve & Google die in erster Linie Geld reinpumpen, aber mit anderer Motivation/Markt.

Was ich nicht beurteilen kann ist die Verwandtschaft zu den Konsolenapis jenseits nvn, die könnte ein Wechsel zu vk leichter machen.

Also nein ich glaube nicht dass es so schnell DX den Rang abläuft, aber es hat viel bessere Aussichten als GL und zeigt das schon jetzt.

Unity und Unreal sind imo noch zu sehr "alte Engines" im Grundaufbau, die müssen auch zuviel alte APIs abdecken. Daher sehe ich die 2.5 Jahre als unkritisch.

danarcho

2018-09-05, 11:00:15

Die API braucht man nicht mit Muell vollklatschen nur damit paar Linux-Hippies sich kein Windows installieren muessen. Das Zeug muss alles langfristig gewartet werden und hat Seiteneffekte.
Ich würde mal sagen, es gibt deutlich unsinnigere Extensions als xfb. Und afaik hat stream out Hardware Support. Zudem bleibts wohl EXT und geht nicht in Core.

Die pessimistische Einschätzung von Ganon teile ich auch nicht. Allein der Android-Support dürfte in Zukunft noch einiges ausmachen, insbesondere weil immer mehr Spiele als Mini-Version dann aufs Handy gebracht werden (siehe Fortnite & PUBG).
Dazu können Entwickler durch MoltenVK auch Mac und IOS einfach mitnehmen. Eine Hoffnung ist ja (und jetzt bitte kein Trolling für diesen Satz), dass durch die Bemühungen von Valve der Linux-Anteil etwas steigt und dadurch die Motivation dort über Vulkan für bessere Performance zu sorgen.
Dass RADV gegenüber dem Windows-Treiber so hinterher hinkt, liegt vor allem an dem LLVM Müll (z.B. kann RADV die shader_ballot ext nicht exposen, weil LLVM die register allocation mit whole wavefront mode nicht gebacken bekommt, neben einem Haufen anderer Unzulänglichkeiten). Ansonsten hat Intel einen recht guten Treiber und Nvidia sowieso, wenn auch closed (die paar Problemchen mit dem neuen Shader Compiler werden die sicher auch noch lösen).

Ganon

2018-09-05, 12:01:10

Allein der Android-Support dürfte in Zukunft noch einiges ausmachen, insbesondere weil immer mehr Spiele als Mini-Version dann aufs Handy gebracht werden (siehe Fortnite & PUBG).

Nur noch mal, um Missverständnisse zu vermeiden. Mein Kontext ist, wie erwähnt, der PC-Spielemarkt. Es bringt mir halt nichts, wenn eine Engine auf irgend einer zugenagelten Plattform (iOS, Android, Switch) Vulkan bzw. MoltenVK/Metal benutzt. Wie Valve auch in ihrer Steam-Play Ankündigung gesagt haben, brauchen die Spiele Vulkan-Support unter Windows, wenn sie schon von sich aus nicht mehrere Plattformen unterstützen wollen. Erst dann habe ich als Endanwender, von etwaigen ekligen Kopierschutzmaßnahmen abgesehen, einen Vorteil davon. Sei es indirekt verbesserter Support von Linux durch WINE oder eben weil die Treiberhersteller mehr Testfälle haben und sich damit die Qualität verbessert.

Und genau das sehe ich halt gerade noch nicht. Klar rede ich hier als Linux-Nutzer aus einer Linux-zentrischen Sicht. Die ganzen Engines haben auch alle OpenGL (ES) Support gerade wegen Android und iOS. Trotzdem ist, soweit ich weiß, Unity die einzige große Engine die mir das von Haus aus überhaupt anbietet das Rendering Backend zu wechseln. Hat jetzt auch nicht gerade dafür gesorgt, dass AAA Spiele OpenGL benutzen. Aber gut, OpenGL ist ein anderes verkorkstes Kapitel.

Aber den meisten Windows Nutzern geht diese Debatte vermutlich eh sonst wo vorbei, da es ihnen egal ist, ob ein Spiel DX12 oder Vulkan benutzt. Vermutlich wird sogar eher DX12 favorisiert.

iuno

2018-09-05, 12:12:09

Aber den meisten Windows Nutzern geht diese Debatte vermutlich eh sonst wo vorbei, da es ihnen egal ist, ob ein Spiel DX12 oder Vulkan benutzt.
Denen ist doch ueberhaupt egal ob ein Spiel DX12,11, DX9, Vulkan oder OpenGL nutzt. Das juckt in der Masse keine Sau, oder um es in gravitationsfelds Worte zu fassen 0,01%. Da ist das Forum hier genausowenig repraesentativ wie irgendeine Linux-Gaming Community. Und selbst wenn es der Performance oder der Optik hilft, die Masse kauft jeden Schrott der genug Marketing hat.

Troyan

2018-09-05, 12:17:37

Auch in diesem Forum ist die API belanglos.

Es ist eben ein Fehler zu glauben, dass die Entwickler sich zu APIs hingezogen fühlen, die deren Leben erschweren.

Es ist eine reine ökonomische Betrachtung.

dildo4u

2018-09-05, 13:32:01

Strange Brigade soll Multi GPU Support unter Vulkan bieten.

https://www.overclock3d.net/news/software/strange_brigade_is_the_first_game_to_support_the_vulkan_api_with_multi-gpu_systems/1

gravitationsfeld

2018-09-05, 18:36:09

Vulkan wird imo immer das Problem haben hinter DX zu sein was die Standardisierung angeht (Demokratie ist langsam).
Weil die meisten AAA-Titel ja auch immer super auf der Hoehe der Zeit sind was Technik angeht und nicht nach drei Jahren immer noch DX11 benutzen. Was ein Quatsch.

Ganon

2018-09-07, 16:17:51

Update zum Transform-Feedback Krams:

https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/26#issuecomment-418530373

Some members of the Vulkan working group are developing a multi-vendor EXT extension for transform feedback with the primary goal of satisfying the needs of the DXVK, vkd3d and ANGLE translation layers. The Vulkan working group does not plan to promote this functionality as a KHR extension or as core functionality because it believes there are better, more forward-looking ways of processing and capturing vertex data with the GPU. The multi-vendor EXT extension should be available soon and is likely to be implemented on those platforms where DXVK, vkd3d and ANGLE translation is required.

Wie vermutet, es wird eine optionale Extension.

edit: Ich sehe gerade, dass auch vkd3d erwähnt wird. Hat DX12 etwas, bei dem die Extension ebenfalls helfen könnte?

gravitationsfeld

2018-09-07, 19:17:20

DX12 hat transform feedback, ja.

Locuza

2018-09-13, 12:52:59

Die R&D-Engine Halcyon von EAs SEED Division hat Vulkan-Support implementiert bekommen und Ende Oktober in München wird ein Vortrag darüber gehalten:
https://twitter.com/gwihlidal/status/1039489001307000833
https://www.meetup.com/de-DE/Khronos-Munich-Meetup/events/253941541/

Vielleicht wird man konkret über die Zukunftspläne und was man mit den neuen APIs vorhat.
Die Frostbite-Engine könnte ein Update bei der Implementierung von explicit APIs vertragen.

iuno

2018-09-14, 00:24:27

Gut dass EA wenigstens doch mal Interesse zeigt. Letztens habe ich auf Twitter gelesen, dass sie in diesem SEED Projekt auf Rust setzen, also doch noch Experimentierfreude da ;)

---

Vulkan has just become the world’s first graphics API with a formal memory model. So, what is a memory model and why should I care?
(https://www.khronos.org/blog/vulkan-has-just-become-the-worlds-first-graphics-api-with-a-formal-memory-model.-so-what-is-a-memory-model-and-why-should-i-care)

AffenJack

2018-09-15, 09:45:21

Mich würde mal interessieren, wieviel der neuen Turingfeatures wohl demnächst als Extensions für Vulkan bereitstehen. Für RTX soll es ja eine Extension geben, aber auch Content Adaptive Shading wurde in Wolfenstein 2 eingebaut:

https://www.techpowerup.com/reviews/NVIDIA/GeForce_Turing_GeForce_RTX_Architecture/images/slide-42.jpg
https://www.techpowerup.com/reviews/NVIDIA/GeForce_Turing_GeForce_RTX_Architecture/10.html

Da W2 ja über Vulkan läuft, müsste das auf einer Vulkanextension basieren oder?

SaschaW

2018-09-15, 11:56:20

AffenJack

2018-09-15, 12:08:16

Ist das nicht nur ein schicker Name für adaptives Multi-Rate Shading?

Viel interessanter finde ich Mesh und Task Shader. Hoffentlich kommt das bald für Vulkan, das ist der Geometry und Tessellation Mist in absehbarer Zeit Vergangenheit :)

Ja ist ein Teil von Variable Rate Shading, wie Nv es nennt, was wahrscheinlich das gleiche ist. Ist das schon länger Teil von Vulkan? Ging mir generell so um die Adoption der neuen Features, Aufwand, wie schnell sowas in Extensions kommt.

Da kann Mesh und Task Shader natürlich viel interessanter sein. Aber bevor die Dinge wirklich verwenden werden und es überhaupt richtig in die API kommt dauert das ja ewig. Mich hat hier verwundert, dass Wolfenstein das schon in nem Testbuild nutzt.

Digidi

2018-09-15, 12:13:30

Ist das nicht nur ein schicker Name für adaptives Multi-Rate Shading?

Viel interessanter finde ich Mesh und Task Shader. Hoffentlich kommt das bald für Vulkan, das ist der Geometry und Tessellation Mist in absehbarer Zeit Vergangenheit :)

AMD hatte ja mit PS und NGG den selben Ansatz waren die bei euch mal deswegen hausieren.

Und so wie ich das Whitepaper und die Techdemo verstehe fängt mesh shader erst richtig an mit tessaltion. Siehe den Abschnitt mit LoD.

iuno

2018-09-15, 12:18:56

NGG ist eine andere Baustelle und ein Sammelbegriff fuer mehrere Dinge. Das genaue Gegenstueck zum Mesh Shader ist der Primitive Shader und was bei Nvidia jetzt Task Shader heisst, heisst bei AMD Surface Shader. Jedenfalls scheint es aus dieser Sicht genau das selbe Konzept zu sein. pixeljetstream kann dazu sicher mehr sagen, ich hatte im Turing Thread auch schon nachgefragt, aber der wird ja leider mit bullshit geflutet.

Waere interessant zu wissen, ob es schon Gespraeche gibt. Da beide Hersteller denselben Ansatz haben, sollte man das doch recht zuegig hin bekommen koennen. Auch im Hinblick auf die naechste Konsolengeneration interessant. Wenn beide der Meinung sind, dass das so hilfreich ist, gibt es ja keinen Grund darauf zu verzichten.

DinosaurusRex

2018-09-15, 12:29:44

Mal ne Frage an die Experten hier:

Ray casting -> ray tracing -> (echtes) voxel rendering. Bzw verhält es sich gegensätzlich für Performance.

Wann können wir letzteres wohl erwarten für Videospiele?

---

Das ist Feuer und Rauch mit Voxel Rendering:

https://www.electronicdesign.com/sites/electronicdesign.com/files/uploads/2015/02/0116_CTE_Peddie_F5.jpg

Digidi

2018-09-15, 13:14:32