Vulkan Grafik-API

[Locuza]

Ich frag mich halt warum sich jetzt bei Turing jeder die Finger danach leckt und bei Vega interessierte es kein Mensch...
Laber mal keinen Blech.
Es gab etliche Berichte, Diskussionen und auch Nachfragen bezüglich Primitive Shader.
Nur hat AMD selber kaum konkrete Informationen darüber veröffentlicht und nach all den Monaten scheint es so, als ob AMD NGG für GFX9/Vega auch begraben hat.

Jetzt hat Nvidia etwas ähnliches präsentiert, wo wir ebenso noch nicht viel über die low-level-details Bescheid wissen, aber es deutet darauf hin das im Gegensatz zu AMD das Ganze nicht auf dem Papier vergammeln wird, sondern das man in den kommenden Wochen mehr Informationen bekommt, open source samples und Entwickler werden dann vermutlich auch Zugang über NvAPI und/oder Vulkan Erweiterungen bekommen.

[dargo]

Ich frag mich halt warum sich jetzt bei Turing jeder die Finger danach leckt und bei Vega interessierte es kein Mensch...
Weils halt Nvidia und nicht AMD drauf steht. :weg:

Spaß bei Seite... dennoch interessant zu sehen wie sich das Blatt plötzlich bei gewissen Herrschaften wendet bezüglich low level wenn Nvidia davon profitiert. ;) Ich kanns nur begrüßen... je mehr Features nur über LL gehen umso schneller wird der DX11 Müll am PC entsorgt.

[pixeljetstream]

Es wird wie üblich nen Batzen GL/Vulkan/Nvapi Extensions geben :)

Task/Mesh Shader und AMDs Lösung mit Primitive Shader gehen in gleiche Richtung, müssen im Featureumfang und Flexibilität aber nicht gleich sein. Da unabhängig entwickelt kann man mit Sicherheit sagen dass sie nicht deckungsgleich sind, aber Schnittmenge gibt es sicher. Da es halt nie mehr als die Marketing slides gab ist es schwer PS einzuschätzen (bei Turing ist das im Moment zwar auch so aber in den nächsten Wochen dann nicht mehr). Das Feature hat imo Riesenpotential, aber ich bin natürlich super biased.

Motion/Feature adaptive shading sind Namen für Techniken die auf der gleichen Extension aufsetzen.

[gravitationsfeld]

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.
NVIDIA veroeffentlicht OpenGL & Vulkan Extensions normalerweise mit dem Release der Karten und verteilt vorher schon an Entwickler. Braucht keiner auf DirectX-Versionen warten.

Task/Mesh Shader und AMDs Lösung mit Primitive Shader gehen in gleiche Richtung, müssen im Featureumfang und Flexibilität aber nicht gleich sein. Da unabhängig entwickelt kann man mit Sicherheit sagen dass sie nicht deckungsgleich sind, aber Schnittmenge gibt es sicher. Da es halt nie mehr als die Marketing slides gab ist es schwer PS einzuschätzen (bei Turing ist das im Moment zwar auch so aber in den nächsten Wochen dann nicht mehr). Das Feature hat imo Riesenpotential, aber ich bin natürlich super biased.
Lustigerweise aber nicht wirklich mit DXR zu verheiraten, zumindest wenn man es fuer mehr als intelligentes Culling etc. benutzt, was den Mesh nicht veraendert.

[pixeljetstream]

Hehe ja, aber ich bin ja auch im rasterization camp, from my cold dead hands ;)
Denke auch dass RT langfristig flexibler wird als nur brute force wie jetzt. Wird spannend wie sich hybrid übers nächste Jahrzehnt entwickelt. Ideen gibt's genug.

[Digidi]

Da es halt nie mehr als die Marketing slides gab ist es schwer PS einzuschätzen (bei Turing ist das im Moment zwar auch so aber in den nächsten Wochen dann nicht mehr).

So so es gab nie mehr als Marketingmaterial:
https://patents.google.com/patent/US20180082399A1/en

Jetzt weiß ich auch warum du es damals nicht lesen wolltest bzw. immer noch nicht willst ;)

[DinosaurusRex]

Apropos "primitive", Im off-topic gehts wieder mal richtig ab:

Wenn man sich ein bisschen Puderzucker auf die Eichel tut, mögen es die Katzen auch. :)


@Arschkrämpfe

Brudi ich kann sehr gut ne Backenmassage machen. Es kitzelt sogar nicht, wenn ich Hand anlege.

[Locuza]

Hehe ja, aber ich bin ja auch im rasterization camp, from my cold dead hands ;)
Denke auch dass RT langfristig flexibler wird als nur brute force wie jetzt. Wird spannend wie sich hybrid übers nächste Jahrzehnt entwickelt. Ideen gibt's genug.
Wie läuft es dann bei Spielen wie z.B. Shadow of the Tomb Raider ab?
Wird Tessellation automatisch ausgeschaltet wenn RTX verwendet wird oder wird nur Geometrie bei dem Raytracing-Vorgang verwendet, welche von Tessellation sowieso nicht modifiziert wird?

Liege ich in der Annahme richtig, dass Raytracing vor der Tessellation-Stage berechnet und deswegen die Geometrie nicht modifiziert werden kann, weil dann falsche Ergebnisse herauskommen würden?
Oder was ist das genaue Problem, wieso man beides (aktuell?) nicht gleichzeitig verwenden kann?

Apropos "primitive", Im off-topic gehts wieder mal richtig ab:
Echt nice das du das Niveau noch in diesem Thread präsent machen möchtest. :freak:
In der Zukunft bitte nicht mehr. ;)

[pixeljetstream]

So so es gab nie mehr als Marketingmaterial:
https://patents.google.com/patent/US20180082399A1/en

Jetzt weiß ich auch warum du es damals nicht lesen wolltest bzw. immer noch nicht willst ;)

Du verstehst nicht dass ein Patent != Implementierung ist. Es wird eine mögliche Implementierung/Konzept beschrieben. Habe den Spaß mit Patenten selbst schon mitgemacht.
Am Ende zählt imo nur dass was der Entwickler tatsächlich zur Verfügung hat, weil das die Methoden/die Abstraktion ist hinter der der Hersteller dann wirklich steht.

[DinosaurusRex]

Echt nice das du das Niveau noch in diesem Thread präsent machen möchtest. :freak:
In der Zukunft bitte nicht mehr. ;)

https://media1.tenor.com/images/7e42ca4f86aa9fb9a712737705cf0368/tenor.gif?itemid=10552876

Ich kann halt trotzig werden wenn man meine Frage einfach ignoriert. Ich bin das mittlere Kind. Menschen wie ich brauchen Aufmerksamkeit.

[Digidi]

Du verstehst nicht dass ein Patent != Implementierung ist. Es wird eine mögliche Implementierung/Konzept beschrieben. Habe den Spaß mit Patenten selbst schon mitgemacht.
Am Ende zählt imo nur dass was der Entwickler tatsächlich zur Verfügung hat, weil das die Methoden/die Abstraktion ist hinter der der Hersteller dann wirklich steht.

In dem Patent sind ja wohl alle wesentlichen Informationen abgebildet. Woher willst du den wissen was im Patent über die Abstraktion steht wenn du nicht reingeschaut hast :rolleyes:

[pixeljetstream]

@Locuza raytracing ist bisher so gebaut dass es komplett unabhängig von Grafik ist. So dass man es eben auch in compute umsetzen kann. Es bekommt rohe Dreiecksdaten die komplett auf der GPU liegen. Es muss also über fixe LODs gearbeitet werden, sowas wie bei REYES dass man dynamisch tesselliert gibt es noch nicht. Alternativ zu den Dreiecken kann man nen Shader bereitstellen der eine intersektion ausrechnet, das ist dann voll flexibel.

[pixeljetstream]

In dem Patent sind ja wohl alle wesentlichen Informationen abgebildet. Woher willst du den wissen was im Patent über die Abstraktion steht wenn du nicht reingeschaut hast :rolleyes:
Weil wie geschrieben ich Erfahrung mit eigenen habe. Daher weiß ich was man in sowas schreibt und was nicht.
Es ist mir nicht nachvollziehbar wie du eine Patentschrift einer spec für sw Entwickler gleichsetzen willst. Was genau ist deine Motivation an der ganzen Diskussion.

[Digidi]

Weil wie geschrieben ich Erfahrung mit eigenen habe. Daher weiß ich was man in sowas schreibt und was nicht.
Es ist mir nicht nachvollziehbar wie du eine Patentschrift einer spec für sw Entwickler gleichsetzen willst. Was genau ist deine Motivation an der ganzen Diskussion.

ähmm ja. In einem patent müssen alle wesentlichen Merkmale festgehalten werden um spätere Rechtsansprüche auch sicher geltend machen zu können. Man merkt es ja auch am Aufwand wie detalliert und Minuziös so ein Patent aufgebaut ist. (Ansonsten würde ein Patent keinen Sinn machen, weil man ja genau die beschriebene Funktion schützen will).

Natürlich schreibt man da nicht jede Kleinigkeit rein und versucht es auch so weit wie möglich zu fassen. Aber die wesentlichen Merkmale/Funktion stehen immer in einem Patent!

Es geht mir darum einen vergleich zu ziehen und vielleicht den Fehler zu finden den AMDs Lösung vielleicht unattraktiv gemacht hat und um Wissen zu sammeln und dazu eignen sich Funktionelle Ansätze meist sehr gut!

[pixeljetstream]

Es wird vermutlich kein Problem auf dem Papier geben, weil die haben ja auch gute Leute. Das Problem ist die Umsetzung und das Zusammenspiel mit dem Rest, da hilft nur Chip Simulation mit realistischen Anwendungen und später dann exaktes Profiling um die Simulationsgüte und die Modelle zu verbessern.

[Locuza]

@ pixeljetstream

Danke für die Antwort. :up:

------

Just tried MoltenVK and the progress since the initial release is amazing - our Vulkan backend now runs without any changes on macOS. It's noticeably slower than our Metal backend but that will hopefully improve. If gfx-rs devs are reading this I'm up for testing a binary ;)
https://twitter.com/zeuxcg/status/1029156707090362368

Dolphin werkelt gerade an zwei Vulkan-Wrappern, MoltenVK und gfx-portability:
https://github.com/dolphin-emu/dolphin/pull/7039#issuecomment-416654945

Das native Metal-Backend wird nicht mehr fortgeführt bzw. vielleicht nur wenn die Leute Zeit haben:
MoltenVK is the solution for now. I simply don't have the time to maintain another backend, even if I did complete the missing features.

At some point in the future I may resurrect this branch, but for now it's dead. If someone does want to pick it up, there's an untested/rebased version in stenzek/metal.
https://github.com/dolphin-emu/dolphin/pull/6385

Ich habe mich nicht mit der Performance befasst, aber aktuell scheinen Wrapper für Vulkan für jegliche API wie Pilze aus dem Boden zu schießen.

[pixeljetstream]

Mein Blog Post über Mesh Shading ist online (6 Uhr morgens Ortszeit hier).
https://devblogs.nvidia.com/introduction-turing-mesh-shaders/
Dazu auch die Präsentation von der Siggraph.
http://on-demand.gputechconf.com/siggraph/2018/video/sig1811-3-christoph-kubisch-mesh-shaders.html

[pixeljetstream]

@Digidi. Ein paar Dinge die hier sinnvoll waren:

Ähnlich zu tessellation ne extra stage in der die Entwickler einfach Cluster culling umsetzen können. Das ist besser als das culling in der Mesh Stage zu machen weil man sich so deren on-chip Allokation spart.

Mehr Dreiecke als Vertices zulassen. Damit kann man höheren vertex re-use erreichen als vorher.

Volle Flexibilität beim Schreiben/Lesen der Daten, jeder thread kann alles.

[Digidi]

Danke für die Infos Pixeljetstream. Gibt es eigentlich schon eine maximale Rate wie viele Polygonen pro Takt durchgeschleust werden können? Wo liegt da das Theoretische Maximum bei Turing.

[pixeljetstream]

Die Angaben der Leistung der Units nach Takt (hier ist VPC relevant) ist leider nur unter NDA verfügbar. Aber irgendwer wird sicher nen Benchmark basteln.

[Digidi]

Die Angaben der Leistung der Units nach Takt (hier ist VPC relevant) ist leider nur unter NDA verfügbar. Aber irgendwer wird sicher nen Benchmark basteln.
Hahaha...
Wann hat das letzte mal jemand an so einen Benchmark gebastel?

Das einzige sinnvolle was es halbwegs dazu gibt ist die Byond3d Suite und die ist aus Lizenzgrunden nicht öffentlich zugänglich.

Carsten von PCGH hatte diese aber der ist ja jetzt leider weg und auf eine Frage hin ob Raff das Programm noch hat nur betretendes schweigen.

Zudem muss der Benchmark ja auf die Mesh Shader angepaßt werden. Das macht do h heute keiner mehr Freiwillig...

[aufkrawall]

Forcierbares AF mit radv:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=3871dd7a92624675bd45d9d596bbe34c33d7bb4d

Gibts mit den Treibern von Nvidia und AMD nicht, toller Hersteller-Service...

[gravitationsfeld]

Es entspricht halt nicht so der Philosophie von low level APIs, dass der Treiber dir da irgendwie deine Werte veraendert. Kann das durchaus verstehen.

[aufkrawall]

Der Enduser kann, in diesem konkreten Fall, nur Vorteile davon haben. Für DX12 bietet es Nvidia ja auch an.

[pixeljetstream]

Blog Post über die restlichen Turing features für Vulkan/OpenGL
https://blog.icare3d.org/2018/09/nvidia-turing-vulkanopengl-extensions.html?m=1

[Locuza]

1. Vulkan bekommt ein neues Synchronisationsmodell mit Timeline, was vermutlich auch das handling von Async Compute verbessern wird?
https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Timeline-Semaphores

2. The Elder Scrolls Online besitzt ein DX11-Backend für Windows-Nutzer und ein OGL-Backend für MacOS.
Nun wird aber letzteres durch Vulkan ersetzt, genauer gesagt MoltenVK:
We have switched the Mac renderer from OpenGL to MoltenVK (Metal) to support the upcoming release of the upcoming MacOS Mojave. To support these changes, we will be updating the minimum specifications for all Mac players in Update 20. These will be as follows:

Operating System: macOS High Sierra v 10.13
Model: Late-2013 27-inch iMac and Newer
https://help.elderscrollsonline.com/app/answers/detail/a_id/42951

[y33H@]

Besaß? Offenbar bleibt's doch bei D3D11 für Windows?

[Locuza]

Es war zu unschön ausgedrückt mit dem "und" + DX11.
Ich wollte nur darauf hinweisen, dass OGL entfernt wird bzw. wurde und stattdessen ein Vulkan-Backend eingebaut.
DX11 bleibt für Windows-Nutzer und vermutlich wird es vorerst(?) kein Vulkan-Pfad für diese Nutzer geben.
Bei bisschen googeln habe ich noch erfahren, dass das Spiel zu Beginn noch DX9 und DX10 unterstützt hatte, bis es später ein DX11-Update gab, welches zur Minimalanforderung wurde.

[y33H@]

Danke für die Aufklärung. Es gab von Anfang schon D3D11 aber noch D3D10 und D3D9 als Fallback.

[Naitsabes]

Gibt es irgendeinen sinnvollen Grund, warum man den Vulkanpfad nicht auch für Windows anbietet?

[Locuza]

Schlechtere Performance/Stabilität und größere Support-Kosten.
Eine neue API anzubieten lohnt sich in der Regel erst, wenn einige Systeme nennenswert profitieren können und man genügend Manpower hat, um eine ausreichend große Testmatrix für einen Launch zu etablieren und im Laufe der Zeit Verbesserungen nachzureichen.
Je nach Implementierung und Sachstand kann sich das ein Entwickler für einen Kundenkreis (vorerst) sparen.

[Naitsabes]

Aber offensichtlich reicht die Qualität aus, um es als einzigen Renderpfad für MacOS zu nutzen? Müssten die Kosten nicht sinken, wenn man sich nur noch um eine API kümmern müsste? Also Vulkan überall?

[iuno]

Langfristig wahrscheinlich schon. Kurzfristig will man vielleicht nicht alles auf einmal umstellen. Am Mac hat man halt MoltenVK mit Metal und vielleicht einer handvoll GPUs mit Metal Treibern. Auf Windows hat man Vendor Treiber von Nvidia, AMD und Intel in verschiedenen Versionen und Hardware-Generationen. Und eingearbeitetes Personal fuer d3d. Kann ja noch kommen, mal schauen. Langfristig sehe ich bei so einer Situation auch keinen Sinn darin, mehrere APIs zu unterstuetzen. Aber dadurch dass man auf einer Plattform wenigstens Vulkan hat, arbeiten sich die Leute ja schonmal ein und es wird vielleicht dann was fuer spaeter.

[Ganon]

Dürfte der Intel Treiber dran Schuld sein. Soweit ich weiß liefert der Vulkan erst ab Skylake und wenn das Spiel so genügsam ist wie es in den Systemanforderungen so herauszulesen ist, würde man damit denen vor den Kopf stoßen.

Optional einfach anbieten wäre es natürlich besser, aber naja...

[gravitationsfeld]

Schlechtere Performance/Stabilität und größere Support-Kosten.
FUD.

[aufkrawall]

Leider würden gerade Mobas und isometrisches Zeugs massiv von LL-only profitieren, und genau diese Spiele erhalten häufig krampfhaft die Kompatibilität für Steinzeit- oder Taschenrechner-Hardware mit 20fps...

[danarcho]

Schlechtere Performance/Stabilität und größere Support-Kosten.
Der Grund dürfte wohl ganz allein bei QA zu suchen sein. Vergleich einfach die ~3 mac systeme gegen die windows vielfalt. Das will alles getestet werden. Wenn das Vulkan backend steht, wirds sicher auch irgendwann für windows nachgereicht, aber das eilt halt nicht.

[Locuza]

Aber offensichtlich reicht die Qualität aus, um es als einzigen Renderpfad für MacOS zu nutzen? Müssten die Kosten nicht sinken, wenn man sich nur noch um eine API kümmern müsste? Also Vulkan überall?
Man hat sich auch extra Mühe für das OS mit OGL gegeben, wo die Treiber vermutlich so gammlig sind, dass es über MoltenVK ein gutes Stück schneller laufen könnte, selbst wenn der Vulkan-Pfad nicht optimal ist, als nativ über OGL.
Jedenfalls Dota2 läuft deutlich schneller und das hat auch keine fortschrittliche Technik, geschweige denn Vulkan-Implementierung.

Ansonsten müsste man natürlich wissen, wie gut die Vulkan-Implementierung schon aktuell im Vergleich zu DX11 ausfällt.
Im Prinzip könnte man auch beide Pfade anbieten und die User auswählen lassen.
Vor 2 Jahren gab es im Forum die Ankündigung das TESO DX12 verwenden wird, die Pläne wurden möglicherweise begraben und langfristig könnte man Vulkan für alle Systeme verwenden.

"Yes, we are planning on a DX12 upgrade and expect that this will give us a number of graphics performance improvements. We cannot provide an ETA at this time, but it is something we’re working towards."

https://forums.elderscrollsonline.com/en/discussion/379602/so-about-directx-12-support

[SaschaW]

Die neuen AMD Treiber (https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-10-1) bringen auch Unterstützung für conservative rasterization mit. Das gabs unter OpenGL bisher nur für NV und Intel :)

[Locuza]

Enlisted, der WW2 MMO Shooter von Gajin, wird RTX für GI umsetzen, möchte das für alle zukünftigen Titel tun und verwendet dafür Vulkan:
https://www.youtube.com/watch?v=AvXra6yqEZs

[danarcho]

Habe ich gerade erst gesehen: 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)

Das ist imho ein ziemlich cooler Schritt in die richtige Richtung. Wenn die Treiber (und Entwickler) das ordentlich anwenden, dann erlaubt es theoretisch deutlich mehr Freiraum um memory instructions umzusortieren, und statt alles mit barriers vollzuklatschen nur auf bestimmte zu warten.

[gravitationsfeld]

Nein, erlaubt es nicht. Du kannst bei GPUs nicht mit Speicher synchronisieren.

Selbst wenn du einen Spinlock mit atomics schreibst provoziert man sofort Deadlocks. Und ordentliche Sachen wie Mutexes gibt's erst recht nicht.

[Complicated]

Achso...HSA ist dann wohl eine urban legend. Da sind sogar atomic reads und writes heterogen möglich...mit Vegas HBCC sogar auf SSDs und SAN oder NVRAM.

[danarcho]

Habe es vielleicht nicht präzise genug formuliert, da ich das gar nicht so high-level meinte.
Ich meinte eher, dass der Compiler dann bestimme loads & stores durch die memory barrier schieben kann, wenn klar ist, welche operationen davon überhaupt betroffen sein sollen.
(also unterschied zwischen acquire, release und dann buffer, image, shared etc.)
Wenn man das nicht unterscheidet, wartet das Programm möglicherweise auf einen load, obwohl die barrier nur dafür sorgen wollte, dass ein store ankommt. Oder ein späterer load kann nicht früher issued werden, obwohl sie auf einen anderen Speicherbereich zugreift.
Aber keine Ahnung, ob das in der Praxis wirklich was ausmacht...

Achso...HSA ist dann wohl eine urban legend. Da sind sogar atomic reads und writes heterogen möglich...mit Vegas HBCC sogar auf SSDs und SAN oder NVRAM.
HSA hat device-side enqueueing und preemption. Du bist aber im Vulkan thread.

[Complicated]

Es ging mir lediglich um die behaupteten Fähigkeiten, oder fehlenden in diesem Fall, einer GPU. Zumal APUs das ja schon lange mittels RMB und FCL demonstrieren cache-kohärent.

[danarcho]

Ok, ich stimme dir zu: Ich denke, man kann bei GPUs über den Speicher synchronisieren. Man könnte sogar schicke producer-consumer persistent threads bauen (macht aber leider keiner). Stattdessen nimmt man lieber Vulkan CS und startet nach jedem Durchlauf einen neuen Kernel. (Oder das gleiche unter OpenCL / CUDA / whatever.)

[aufkrawall]

Yey, schon wieder einen Nvidia-Treiber Bug gefunden: AF forcieren via DXVK macht Fehler in The Forest, mit radv geht es natürlich wieder problemlos. Ich reporte jetzt nichts mehr an Nvidia, mir reichts dicke mit dem Müll...

[gravitationsfeld]

Es ging mir lediglich um die behaupteten Fähigkeiten, oder fehlenden in diesem Fall, einer GPU. Zumal APUs das ja schon lange mittels RMB und FCL demonstrieren cache-kohärent.
Ich weiss dass die Caches kohaerent sind (uebrigens auch nur mit Onion, nicht mit Garlic). Das hat aber nichts mit dem Thema zu tun. Damit kannst du CPU und GPU synchronisieren, aber nicht Barriers auf der GPU vermeiden. Ich kann nicht mit einem Compute-Shader auf den anderen warten mit Atomics. Das deadlockt.

Yey, schon wieder einen Nvidia-Treiber Bug gefunden: AF forcieren via DXVK macht Fehler in The Forest, mit radv geht es natürlich wieder problemlos. Ich reporte jetzt nichts mehr an Nvidia, mir reichts dicke mit dem Müll...
Wenn du AF forcierst dann hast du je nach Hardware eben falsche Resultate. Das versuch ich dir schon seit langer Zeit zu erklaeren.

[aufkrawall]

Wenn du AF forcierst dann hast du je nach Hardware eben falsche Resultate. Das versuch ich dir schon seit langer Zeit zu erklaeren.
Aha, deshalb geht es mit DX11 ja auch mit Nvidia ohne Fehler in dem Spiel. :rolleyes:
Die Blood Decals in der Serious Engine sind mit Nvidia übrigens schon seit Jahren kaputt, gibt immer noch hässliche Raster. Bestimmt auch wieder Zufall...

Edit: Ganz aktuell:
https://github.com/mpv-player/mpv/issues/6172#issuecomment-432553548
Auch schon wieder ewig kaputt... :facepalm:

[gravitationsfeld]

DX11-Treiber machen so einiges ohne dein Wissen damit es funktioniert. Versteh mich nicht falsch, es ist moeglich dass der NVIDIA-Treiber da einen Bug hat, aber es ist ziemlich unwahrscheinlich.

[vinacis_vivids]

NVIDIA Treiber hat genügend Bugs, braucht man nicht heruntergespielen.

[gravitationsfeld]

AMD-Treiber hat genügend Bugs, braucht man nicht herunterspielen.

[Unicous]

Intel-Treiber hat genügend Bugs, braucht man nicht herunterspielen.

Oh wait, das ist ja hier nicht der Spam-Thread, sorry.

[Kriton]

Na komm, als rethorisches Stilmittel war das voll ok.

[Locuza]

Der Tag ist gekommen, nach der Aussage vor vielen Monaten das man in Zukunft bei Linux den Renderer standardmäßig von OGL4.3 auf Vulkan umstellen wird, hat es UE 4.21 nun getan:
New: Linux Defaults to Vulkan Renderer

Linux now uses Vulkan as the default renderer when available. In the event the API cannot be initialized, the Engine will fall back OpenGL without notification.

From the Project Settings, you can use the Target RHIs to add or disable a particular RHI or use command line switches -vulkan and -opengl4 to disable the fallback.
https://www.unrealengine.com/en-US/blog/unreal-engine-4-21-released

Und:
With the help of Samsung, Unreal Engine 4.21 includes all of the Vulkan engineering and optimization work that was done to help ship Fortnite on the Samsung Galaxy Note 9 and is 100% feature compatible with OpenGL ES 3.1. Projects that utilize Vulkan can run up to 20% faster than the same project that uses OpenGL ES.

[aufkrawall]

Und:
Vorerst nur Mobile-Grafikdetails. ;D (https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1059855-unreal-engine-4-21-released-linux-now-defaults-to-vulkan?p=1059870#post1059870)

[Ex3cut3r]

Adaptive Shading auf Turing:
https://www.computerbase.de/2018-11/geforce-rtx-adaptive-shading-wolfenstein-2-test/

Sieht gar nicht sooo schlecht aus, nett das die Jungs von Wolfenstein 2 das relativ schnell eingebaut haben. @ 3440x1440 Max komme ich jetzt ständig @ CAS Balanciert auf 150-175 FPS. Wäre sicherlich bei Doom Eternal auch sehr lecker, mit DS Spielchen und so. :up:

[gravitationsfeld]

Hat NVIDIA eingebaut.

[Ex3cut3r]

Oh Ok, aber ihr habt es ja erlaubt. ;)

[gravitationsfeld]

Nein, Machine Games.

[Ex3cut3r]

:freak: Achso, na dann ziehe ich meinen Comment oben züruck, wahrscheinlich hat Machine Games einen nettes Sümmchen dafür bekommen.

[Blediator16]

https://www.youtube.com/watch?v=-aYr0AylpmQ

Nennt man dies dann auch schon cheating?

[CompuJoe]

Uff, das sieht schon strange aus.

[Ex3cut3r]

Checke ich nicht im Video, welche Stufe nutzt er? Es gibt 3 Stufen bei mir zur Auswahl (siehe auch CB) das CAS Spiel-Performance sieht am schlechtesten aus, bringt aber meisten FPS, mir scheint CAS Balanciert der Sweetpot zu sein, ich sehe keinen Unterschied, und die FPS steigen sehr gut an. Irgendwann ist es auch mal gut, Turing immer negativ reden zu wollen. :rolleyes:

[gravitationsfeld]

Das funktioniert uebrigens bei Wolfenstein wegen forward shading. Mit deferred shading geht es soweit ich weiss nicht, was gefuehlt 95% der Spiele am Markt ausmacht.

[Blediator16]

Checke ich nicht im Video, welche Stufe nutzt er? Es gibt 3 Stufen bei mir zur Auswahl (siehe auch CB) das CAS Spiel-Performance sieht am schlechtesten aus, bringt aber meisten FPS, mir scheint CAS Balanciert der Sweetpot zu sein, ich sehe keinen Unterschied, und die FPS steigen sehr gut an. Irgendwann ist es auch mal gut, Turing immer negativ reden zu wollen. :rolleyes:

Die BQ ist halt nicht mehr so Inn wie noch vor ein paar Jahren (AMD AF) *Hust* :cool:
Oder auch der frisch ins Gespräch gebrachte "AMD cheating Tess Schalter" (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11864451#post11864451) :D

[Savay]

Eigentlich ist das doch nur ne clevere Optimierung! Je mehr der Trend Richtung UHD und höhere Auflösungen geht umso mehr muss man denke ich halt von reinem Bruteforce weg als bisher schon.
Und solange es optional ist, ist doch auch alles ok.

Nur ist es bei Wolf 2 selbst auch irgendwie nicht mehr als ein reiner Demonstrator...das rennt ja so oder so flott genug. :ulol:
Für die Praxis momentan also eher komplett überflüssig...und die Karten die es am ehesten bräuchten (also die langsamsten) können es eh noch nicht...was die Umsetzung etwas absurd dastehen lässt.

Was mich primär interessiert...anhand welcher Kriterien wird entschieden welcher Bereich in welcher Auflösung gerendert wird?!?

Mit Eye-Tracking hätte man ja irgendwann nen wirklich sinnvollen Input dafür...das wird dann zukünftig aber wohl eher für VR relevant (und dann müsste man auch erstmal die passende HW dafür haben)...ansonsten bleibt ja nur gleichfarbige Flächen ohne viele Details irgendwie zu erkennen und dort dann die Genauigkeit runterzuschrauben...was IMHO aber irgendwie ne Krücke bleibt.

[kruemelmonster]

Mit dem vorletzten NV Vulkan Dev Treiber 417.42 ist u.a. folgende Änderung hinzugekommen:

Expose two transfer queues on Pascal and above

Die Endkundentreiber haben die zweite Transfer Queue noch nicht bekommen, den aktuellen Vulkan Dev Treiber 417.63 werd ich heute Abend mal installieren, dürfte dann wie beim 42er wieder freigeschaltet sein.

Bringt uns die zweite Transferwarteschlange was bei schon existierenden Spielen, oder ist das Vorarbeit für künftige Geschichten?

[Chris Lux]

Bringt uns die zweite Transferwarteschlange was bei schon existierenden Spielen, oder ist das Vorarbeit für künftige Geschichten?
Wenn du eine Engine hat, welche Feedback-Infos von der GPU zurück zur CPU pipen muss, definitiv. Ich bin gerade nicht im Bilde ob idTech6+ noch Feedback-Infos generiert wie idTech5 es tat. Aber dies wäre ein Fall wo es auf jeden Fall etwas bringt. Man kann VTexture-Daten auf die GPU per DMA schieben, während man noch den Feedback-Buffer runterzieht und gleichzeitig ggf. schon einen anderen Pass rendern kann.

[Ganon]

Detroid - Become Human benutzt die Vulkan API:

https://www.epicgames.com/store/de/product/detroit-become-human/home?epic_affiliate=maria_cmg&epic_gameId=detroit-become-human

Die anderen beiden Titel (Beyond Two Souls und Heavy Rain) von Quantic Dream, die ebenfalls noch kommen, benutzen hier aber DX11.

[dildo4u]

Stadia nutzt Vulkan als API,bin gespannt ob wir jetzt eine umfangreichere Nutzung im PC Bereich sehen.

[Gast]

Nicht nur Vulkan sondern auch Linux (Debian)! Das ist der viel grössere Knaller an der Sache!

[Kriton]

Bei allem Respekt: Was hätten sie denn sonst nutzen sollen?

[Ganon]

Bei allem Respekt: Was hätten sie denn sonst nutzen sollen?

FreeBSD, so wie Sony! *scnr*

[Gast]

Bei allem Respekt: Was hätten sie denn sonst nutzen sollen?

Fuchsia

[Kriton]

Eigentlich bezog ich mich auf Vulkan und nicht Linux.

[aufkrawall]

Vulkan ist mit Android/ChromeOS schon Teil ihres Ökosystems, warum etwas anderes nehmen?

[dargo]

Detroid - Become Human benutzt die Vulkan API:

https://www.epicgames.com/store/de/product/detroit-become-human/home?epic_affiliate=maria_cmg&epic_gameId=detroit-become-human

Hmm... steht alles wieder auf "TBD".

[pixeljetstream]

Slides meiner Präsentation von der GTC
https://on-demand.gputechconf.com/gtc/2019/presentation/_/s9909-nvidia-vulkan-features-update.pdf
Es gibt auch eine Aufzeichnung dazu
https://on-demand.gputechconf.com/gtc/2019/video/_/S9909/

Mehr oder weniger "alles außer Raytracing" ;) wobei coarse rate shading fehlt, das war Teil des VR talks.

[Unicous]

No Man's Sky Vulkan Update (https://www.nomanssky.com/2019/04/vulkan-update/)

[Birdman]

World War Z hat auch nebst DX11 auch Vulkan mit an Bord.
Läuft aber offensichtlich sehr bescheiden (also der Vulkan Renderer), mit nVidia auf jedenfall und was man so hört/liest auch mit AMD

[gravitationsfeld]

Ist sehr wahrscheinlich wieder wegen Pipelines die kompiliert werden. Sieht hier so aus als waere es abgesehen davon schneller: https://www.youtube.com/watch?v=CZFn8LBihhE

[aufkrawall]

Zumindest mit Vega, mit Turing langsamer.

[pixeljetstream]

Kleines Hobbyprojekt https://github.com/nvpro-samples/glsl_indexed_types_generator

[dargo]

World War Z hat auch nebst DX11 auch Vulkan mit an Bord.
Läuft aber offensichtlich sehr bescheiden (also der Vulkan Renderer), mit nVidia auf jedenfall und was man so hört/liest auch mit AMD
Also zumindest hier lese ich was anderes.
http://www.pcgameshardware.de/World-War-Z-Spiel-55590/News/Radeons-schneiden-in-Technik-Test-besser-als-Geforces-ab-1280318/

Benchmarks
https://gamegpu.com/action-/-fps-/-tps/world-war-z-test-gpu-cpu

[Birdman]

Es ruckelt und stottert halt einfach unter Vulkan - wer das gut findet darf sich gerne am mehr an FPS bei den Radeons freuen.

[Denniss]

Gibt es eine verständlichen Test der das mal näher angeht ?
Ruckeln/Stottern sollte ja in den Frametimes (1% Low) ersichtlich sein.

[dargo]

Es ruckelt und stottert halt einfach unter Vulkan - wer das gut findet darf sich gerne am mehr an FPS bei den Radeons freuen.
Nur weil es auf Nvidia aktuell kacke läuft ist es jetzt unbrauchbar? Es gibt offenbar Systeme wo Vulkan dufte läuft.

-55YbRF84ac

[dildo4u]

https://www.amd.com/de/gaming/world-war-z


Ich mein das Game hat AMD Co Marketing klar es es sofort ordentlich läuft,NV wird sich das grad angucken und was per Treiber machen genau wie Vorher bei Doom und Wolfenstein 2.

[dargo]

Von den reinen Frames her glänzt Nvidia selbst unter DX11 in dem Spiel nicht. Ich meine RX Vega64 (LCE) = RTX 2080 ist auch nicht unbedingt der Normalzustand.

[aufkrawall]

Kann einfach sein, dass schon vorher länger gespielt wurde und die Shader entsprechend gecached sind.

Das Spiel scheint aber auch mit DX11 eine super Performance für die moderne Optik zu haben. Sieht sehr nach Unreal Engine 4 aus, aber deklassiert sie bei der Performance völligst. :freak:

[dildo4u]

Ich sehe das eher so das es komisch wäre wenn AMD nicht ideal Performt so lange das Game eine Umsetzung von den Konsolen ist.
Die Entwickler wissen ja jetzt schon das auch die näste Generation AMD nutzen wird,daher macht es natürlich Sinn jetzt schon auf Ryzen und GCN zu optimieren.
Sony und MS setzen diesmal großen Wert drauf das alle Games die jetzt erscheinen auch auf den neuen Konsolen gut laufen,Idealerweise werden dann einfach die fps von 30 auf 60 angehoben.
Das macht relativ wenig Aufwand da es die PC Version eh schon kann.

[dargo]

Ich sehe das eher so das es komisch wäre wenn AMD nicht ideal Performt so lange das Game eine Umsetzung von den Konsolen ist.

Was ist denn heute keine Konsolenumsetzung? Auch diese Schlussfolgerung ist mir zu plump. Nach dem Schema müsste es zu 99,x% der Games RX Vega64 = RTX 2080 bsw. GTX 1080TI heißen, ist es aber nicht.

[HOT]

Nutzt das vielleicht extrem viele Drawcalls? Wie ist denn die DX11-Performance bei AMD?

[dargo]

Ganz bestimmt nicht. Dann stände AMD gegenüber den Geforces unter DX11 nicht so gut in 1080p da.

[dildo4u]

No Man's Sky Vulkan Benches.

https://www.golem.de/news/hello-games-no-man-s-sky-mit-vulkan-api-auf-radeons-viel-flotter-1904-140946.html

[Locuza]

No Man's Sky Performancetabelle:
https://abload.de/img/nomanssky9cjf8.jpg
https://www.computerbase.de/2019-04/no-mans-sky-vulkan-support/#update1

Golem hat seine eigenen Werte bei der Geforce verwechselt, wo die Performance mit Vulkan sinkt und nicht steigt.

[dildo4u]

Ich denke die Werte können stimmen NV hat auch bei World War z Performance Verluste,das es noch keine Treiber Anpassung für Vulkan gibt.Ich denke auch das AMD noch schneller wird,der Vulkan Support für No Mans Sky soll erst im Sommer aus der Beta kommen.

[Ganon]

Golem hat seine eigenen Werte bei der Geforce verwechselt, wo die Performance mit Vulkan sinkt und nicht steigt.

Wurde wohl heimlich von Golem gefixt. Steht jetzt korrekt da. Ich frag mich ja wie das auf schwächeren Systemen aussieht. "Mittelklasse Grafikkarten" mit einer 4,7Ghz CPU ist jetzt imo nicht unbedingt ein homogenes System.

Kann's leider nicht selbst testen. Hello Games gibt die Experimental wohl nur Steam-Nutzern.

Ansonsten ist sicherlich noch Luft nach oben, bevor das Feature für alle raus kommt. Ich denke einen sowieso schon sehr wackeligen OpenGL Renderpfad schreibt man nicht so einfach auf Vulkan um.

[dargo]

Wurde wohl heimlich von Golem gefixt. Steht jetzt korrekt da. Ich frag mich ja wie das auf schwächeren Systemen aussieht. "Mittelklasse Grafikkarten" mit einer 4,7Ghz CPU ist jetzt imo nicht unbedingt ein homogenes System.

Welche großen Überraschungen erwartest du denn? Mit einer schwächeren CPU werden aus den +63% logischerweise noch etwas mehr auf Radeon.

btw.
Ich finds immer wieder interessant zu sehen mit welcher Gülle an APIs der PC die letzten Jahre hantieren musste. Nur durch eine moderne API rutscht eine Grafikkarte selbst im GPU-Limit plötzlich in eine ganz andere Leistungsklasse. Nicht zu vergessen, das hier ist nur ein "angeflanschtes" Vulkan.

[Ganon]

Welche großen Überraschungen erwartest du denn? Mit einer schwächeren CPU werden aus den +63% logischerweise noch etwas mehr auf Radeon.

Da ich gerade für das Spiel nur eine GTX 1060 habe, interessiert mich halt das Verhalten dort.

[Ganon]

OpenGL (Treiber-)Diskussion und dazugehöriges Benchmarking hier hin (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=594595) ausgelagert.

Die Vorteile von Vulkan gegenüber OpenGL können hier natürlich weiter hier besprochen werden, aber da es zu sehr ins spezifische Benchmarking hauptsächlich von OpenGL ging, erst mal ins Benchmarking Unterforum verschoben.

[dargo]

Hieß es früher nicht immer wieder unter low level läge die ganze Verantwortung beim Spieleentwickler? ;)
http://www.pcgameshardware.de/World-War-Z-Spiel-55590/News/Geforce-Treiber-1281622/

[][immy]

Hieß es früher nicht immer wieder unter low level läge die ganze Verantwortung beim Spieleentwickler? ;)
http://www.pcgameshardware.de/World-War-Z-Spiel-55590/News/Geforce-Treiber-1281622/

Im Grunde schon, aber man kann Treiber natürlich trotzdem schlecht schreiben ;)
Bei Mental (worauf vulkan ja basiert) brauchte AMD ja auch ein paar Anläufe

[Demirug]

Hieß es früher nicht immer wieder unter low level läge die ganze Verantwortung beim Spieleentwickler? ;)
http://www.pcgameshardware.de/World-War-Z-Spiel-55590/News/Geforce-Treiber-1281622/

Wenn du einen Treiber brauchst ist es nicht low level. Vulkan ist lower level als OpenGL. Auf dem PC will heute aber niemand ernsthaft wirklich low level programmieren da es dann nur noch exakt mit der Hardware laufen würde für die es programmiert wurde. IMHO war das letzte was auf dem PC wirklich low level programmiert wurde VGA Chips.

[dargo]

Ja... low level ist eigentlich der falsche Begriff. Lower level wäre richtig. Ich bin echt jetzt schon gespannt ob es in Zukunft noch lower geht als DX12/Vulkan.

[Demirug]

Ja... low level ist eigentlich der falsche Begriff. Lower level wäre richtig. Ich bin echt jetzt schon gespannt ob es in Zukunft noch lower geht als DX12/Vulkan.

Signifikant tiefer geht es nur noch wenn sich die Hersteller auf so etwas wie x86-64 oder Arm7 bei den CPUs einigen könnten.

[aufkrawall]

Wird wohl wie bisher ein Sony-Ding bleiben, wenn es nicht mal MS auf der XB macht.

[pixeljetstream]

"explicit API" ist das Stichwort was Khronos verwendet, besser als low-level. Imo macht "noch lower" wirtschaftlich keinen Sinn. Im Endeffekt wird per extensions eh schon mehr geboten als woanders.

[dargo]

Imo macht "noch lower" wirtschaftlich keinen Sinn.
Das hatten beim Wechsel auf DX12/Vulkan auch schon einige Entwickler hier behauptet. :wink:

[aufkrawall]

Nur stehen die letzten paar Prozent Performance-Gewinn in keinem Verhältnis zum Aufwand und dem Einbüßen der Plattform-Portabilität.

Der AMD Vulkan-Treiber schmeißt durch den PAL-Abstraktionslayer btw. auch teilweise CPU-Leistung weg. Interessiert auf der PC-Plattform nur niemanden.

[pixeljetstream]

@Dargo, Weil jeder darunter was anderes versteht. Imo bekommen wir den nächsten großen API design umbruch irgendwann wenn man das meiste direkt aus dem shader code ausführen kann.

[hmmm]

Der AMD Vulkan-Treiber schmeißt durch den PAL-Abstraktionslayer btw. auch teilweise CPU-Leistung weg. Interessiert auf der PC-Plattform nur niemanden.
Wie kommst du darauf? Wieviel "schmeißt" AMD denn durch PAL auf CPU Seite weg?

[aufkrawall]

Wie kommst du darauf? Wieviel "schmeißt" AMD denn durch PAL auf CPU Seite weg?
Jedenfalls mehr als nichts:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11923823&postcount=37

[Gast]

"explicit API" ist das Stichwort was Khronos verwendet, besser als low-level. Imo macht "noch lower" wirtschaftlich keinen Sinn.


Nachdem Moores Law defakto tot ist, könnte sich das umkehren.

Jahrelang wurde schnellere Hardware immer billiger, wodurch es wirtschaftlich natürlich sinnvoll war, Software nicht unbedingt auf höchstmögliche Effizienz zu programmieren, sondern auf niedrigstmögliche Entwicklungszeit.

Nachdem es danach aussieht, dass in Zukunft Mehrperformance in Hardware auch mehr kosten wird, könnte sich das umkehren.

Das würde natürlich bedeuten, dass Software immer mehr Standardisiert wird, da es keinen Sinn macht das selbe Problem X-Fach zu implementieren und nur die wenigsten die Manpower haben werden das umzusetzen.

[AwesomeSauce]

Eine Frage an die Entwickler hier im Forum, angelehnt an die Memory Präsentation hier: https://www.youtube.com/watch?v=rXSdDE7NWmA

Verschiedene GPUs verfügen über eine unterschiedliche Anzahl Heaps (Intel 1, NV 2, AMD 3). Nur AMD stellt derzeit einen Heap des Typs DEVICE_LOCAL und HOST_VISIBLE zur Verfügung (allerdings nur 256 MiB gross).

Wird dieser Heap derzeit von Spielen genutzt und ist es absehbar, dass Intel und NV hier nachziehen werden? Anders gefragt, bringt dieser Heap messbare Performancevorteile?

[danarcho]

Eine Frage an die Entwickler hier im Forum, angelehnt an die Memory Präsentation hier: https://www.youtube.com/watch?v=rXSdDE7NWmA

Verschiedene GPUs verfügen über eine unterschiedliche Anzahl Heaps (Intel 1, NV 2, AMD 3). Nur AMD stellt derzeit einen Heap des Typs DEVICE_LOCAL und HOST_VISIBLE zur Verfügung (allerdings nur 256 MiB gross).

Wird dieser Heap derzeit von Spielen genutzt und ist es absehbar, dass Intel und NV hier nachziehen werden? Anders gefragt, bringt dieser Heap messbare Performancevorteile?
Das hängt ganz von der Art GPU ab. Du kommst halt um die Physik nicht drum herum: Eine APU zum Beispiel hat sowieso nur den DRAM als heap. Ob und wie viel davon dann host visible ist, hängt ein bisschen vom memory controller und dann vom kernel driver ab.
Ob der Heap device-local ist, ist für die Funktionalität erstmal egal, dabei geht es eigentlich nur um Bandbreite und Latenz, je nachdem wer zugreifen möchte.
Bei dGPUs ist PCIe halt der Flaschenhals, wenn du viele Daten von CPU und GPU aus (gleichzeitig) verwendest. Ich denke, bei der Vega ist der Heap ein Nebenprodukt von ROCm/HBCC. Aber um deine Frage zu beantworten: ich glaube außerhalb der Konsolen nicht, und würde auch bezweifeln, dass sich daran in (nächster) Zukunft etwas ändert. Anwendungen findest du wahrscheinlich eher in der Compute-Ecke.
Ich glaube, der 3. AMD-Heap ist physikalisch der gleiche Speicher

(Und jetzt hoffe ich mal, dass ich keinen Quatsch erzählt habe, immer vor die Grafik-Experten hier) :)
Das war wohl mindestens teilweise grober Unsinn °°. Danke, YoRHa2B, für die Richtigstellung

[pixeljetstream]

Nachdem Moores Law defakto tot ist, könnte sich das umkehren.

Jahrelang wurde schnellere Hardware immer billiger, wodurch es wirtschaftlich natürlich sinnvoll war, Software nicht unbedingt auf höchstmögliche Effizienz zu programmieren, sondern auf niedrigstmögliche Entwicklungszeit.

Nachdem es danach aussieht, dass in Zukunft Mehrperformance in Hardware auch mehr kosten wird, könnte sich das umkehren.

Das würde natürlich bedeuten, dass Software immer mehr Standardisiert wird, da es keinen Sinn macht das selbe Problem X-Fach zu implementieren und nur die wenigsten die Manpower haben werden das umzusetzen.
Das Featureset verändert sich, das heißt imo nicht zwangsläufig, dass es lower level für Benutzer wird. Aber jeder mag darunter was anderes verstehen. Für mich heißt lower level weniger Abstraktion, was bedeutet, dass es mehr Architektur spezifisch wird.
Das ist imo nicht das gleiche wie neue Abstraktion, neue Features die Fähigkeiten exposen die es so vorher nicht gab.
Ich stimme Dir zu, dass wir mehr "Cleverness" brauchen um Fortschritt zu machen, mehr Features die es den Entwicklern ermöglichen Arbeit einzusparen und besser auszudrücken was genau sie vorhaben.
Und auf Hardware Seite eben effiziente Implementierung dies zu unterstützen. Was bedeutet, dass die Abstraktion diesen Raum noch hergeben muss, um zu innovieren.
Außerdem sehe ich auch wie unterschiedlich die HW verschiedener Hersteller im Detail ist, dass macht imo es nicht trivial da nen noch dünneren layer zu haben.
Aber mag sein dass diese Features der Zukunft von anderen als low level bezeichnet werden, weil man mehr Aufgaben übernehmen kann. Deswegen ist das mit dem Begriff echt schwer ;)

[YoRHa2B]

Nur AMD stellt derzeit einen Heap des Typs DEVICE_LOCAL und HOST_VISIBLE zur Verfügung (allerdings nur 256 MiB gross).
[...]
Anders gefragt, bringt dieser Heap messbare Performancevorteile?
Ja, tut er. Für dynamische UBOs etc. sollte man den auf jeden Fall nutzen, sonst lässt man gut und gerne 5% Leistung liegen.

NV wird sowas wohl in absehbarer Zeit nicht (https://github.com/doitsujin/dxvk/issues/267#issuecomment-393687696) unterstützen, aber man kann ja einfach auf einen nicht-DEVICE_LOCAL-Memory Type ausweichen, wenn man keinen findet.

[hmmm]

Jedenfalls mehr als nichts:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11923823&postcount=37
Also ich sehe hier keinen direkten Zusammenhang. Wie kommst du darauf es läge grundsätzlich an PAL?

[dildo4u]

World War z mit gefixten NV Treiber,komischerweise holt die 2080 in 4k auf passt irgendwie nicht zu den Specs.

https://www.techspot.com/review/1848-radeon-vii-vs-geforce-rtx-2080/

[dargo]

Was ist daran komisch? Nvidia selbst schrieb im "GPU-Limit".

[dildo4u]

Hat die Radeon nicht fast die doppelte Bandbreite daher wundert mich das der Vorsprung in 4k schmilzt.

[dargo]

Was soll die Bandbreite bringen wenn sie nicht limitiert? Das Ding braucht für Games keine 1TB/s, müsstest du eigentlich wissen.

[dildo4u]

Schätze mal Vulkan löst dort Bremsen die es vorher im CPU Limit gab,normal war es ja immer so das AMD in höherer Auflösung besser wurde.

[robbitop]

Denke auch, dass bei 4K einfach der CPU Einfluss abnimmt und das GPU Limit die Performance zu (nahezu?) 100% bestimmt. Entsprechend nimmt der Abstand zur stärkeren GPU zu.
Gerade die zusätzlichen INT ALUs haben dann ja auch mehr zu tun im Durchschnitt. Pixel/Geometrieverhältnis. (und PP FX)

[aufkrawall]

Es kann auch Auslastungsprobleme unabhängig vom CPU-Limit geben, gegen die höhere Auflösungen helfen.

[dargo]

Schätze mal Vulkan löst dort Bremsen die es vorher im CPU Limit gab,normal war es ja immer so das AMD in höherer Auflösung besser wurde.
Das siehst du falsch. Zur Zeit Grenada/Hawaii war AMD in niedrigeren Auflösungen etwas schlechter aufgestellt. Das hat sich seit Vega geändert sofern die CPU nicht limitiert.

[robbitop]

Es kann auch Auslastungsprobleme unabhängig vom CPU-Limit geben, gegen die höhere Auflösungen helfen.

ja so meinte ich das auch. Beides: Limits und Auslastung

[robbitop]

Das siehst du falsch. Zur Zeit Grenada/Hawaii war AMD in niedrigeren Auflösungen etwas schlechter aufgestellt. Das hat sich seit Vega geändert sofern die CPU nicht limitiert.

Hohe Auflösung dürfte bzgl Granularität helfen (Wavefrontsize / Verhältnis CUs zu SEs). In der Praxis hattest du iirc aber gezeigt, dass das nicht der Fall ist, oder? Bzw nicht signifikant.

Der Rasterizer ist seit Vega (bzw sogar zT Polaris) aber kaum noch ein Bottleneck.

[dargo]

Hohe Auflösung dürfte bzgl Granularität helfen (Wavefrontsize / Verhältnis CUs zu SEs). In der Praxis hattest du iirc aber gezeigt, dass das nicht der Fall ist, oder?
Da musst du mich mit jemanden verwechseln. Natürlich hatte damals höhere Pixellast bei AMD etwas geholfen.

[Birdman]

Das siehst du falsch. Zur Zeit Grenada/Hawaii war AMD in niedrigeren Auflösungen etwas schlechter aufgestellt. Das hat sich seit Vega geändert sofern die CPU nicht limitiert.
Nein, nicht wirklich.
Allerdings würd ich generell nicht sagen dass Karten des einen oder andern Vendors besser oder schlechter mit der Auflösung skalieren.
Die einzigen Fälle wo man so ein Verhalten deutlich beobachten kann, ist i.d.R. bei Spielen wo die Karte in FHD eine miserable Auslastung hat. (weil CPU zu schwach, Spiel/Engine den GPU Vendor nicht mag oder der Treiber noch massig Defizite hat)

Ansonsten ist die Skalierung alles eine Frage der CPU und was für GPUs (Differenz der Leistungklasse) man vergleicht.

[aufkrawall]

Nein, nicht wirklich.

Doch, doch. Eine 290X konnte mit einer 780 Ti häufig erst in WQHD mithalten, trotz völligen GPU-Limits. Mit 580 vs. 1060 verschieben sich die Differenzen mit der Auflösung hingegen kaum noch.

[Birdman]

Doch, doch. Eine 290X konnte mit einer 780 Ti häufig erst in WQHD mithalten, trotz völligen GPU-Limits. Mit 580 vs. 1060 verschieben sich die Differenzen mit der Auflösung hingegen kaum noch.
4K: R7 vs 2080ti: 100% vs 140%
FHD: R7 vs 2080ti: 100% vs 130%

4K: R7 vs 2080: 100% vs 110%
FHD: R7 vs 2080: 100% vs 115%

4K: R7 vs 1080: 100% vs 80%
FHD: R7 vs 1080: 100% vs 90%


oh wait, skaliert die R7 nun mit steigender Auflösung besser oder schlechter?
Oder ist das ganze doch nur eine Frage was man miteinander vergleicht?

[aufkrawall]

Das wird eher an der Anzahl der HBM2-Stacks liegen, und nicht an irgendeinem Detail der Architektur/des Chips (worum es ging)...

[Tesseract]

mit steigender auflösung schlägt tendenziell der effektive arithmetikdurchsatz durch und andere dinge rücken mehr in den hintergrund.

[Ätznatron]

Laminar Research (XPlane) präsentiert den Stand der Vulkan-Implementierung auf der FlightSimExpo (https://www.youtube.com/watch?v=WuUaq7_9CLo), ab etwa 4:44:00 (Beginn des gesamten Vortrags ab 4:00:00).

Die Grafik im Anhang zeigt geringere Zuwächse bei nVidia-Hardware, bei AMD-GPUs dagegen starke Verbesserungen:

[dargo]

Witzig im Zusammenhang vor allem, dass die Entwickler eine RX480 mit der GTX980 TI unter Vulkan gleichstellen. :D

https://abload.de/thumb/nvwujpt.jpg (https://abload.de/image.php?img=nvwujpt.jpg) https://abload.de/thumb/amdvpjq8.jpg (https://abload.de/image.php?img=amdvpjq8.jpg) https://abload.de/thumb/amd-nvpkjdt.jpg (https://abload.de/image.php?img=amd-nvpkjdt.jpg)

btw.
Das hier dürfte 2020 echte Konkurrenz für X-Plane werden. Und sollte zu 99,x% mit nativen DX12 kommen. ;)

ReDDgFfWlS4

[hmmm]

Witzig im Zusammenhang vor allem, dass die Entwickler eine RX480 mit der GTX980 TI unter Vulkan gleichstellen. :D

Egal wie, nvidia muss schneller sein! ;)
Aber eigentlich einfach nur traurig.

[Ätznatron]

Wieso traurig?

Das sind die beiden Karten, die LR üblicherweise benutzt. Das hat nichts mit irgendwelchen Vorlieben für einen Hersteller zu tun.

[pixeljetstream]

Genau das ist einfach nur Treiber CPU Benchmark aus ihrer Sicht.

[Ätznatron]

Es zeigt deutlich, dass selbst bei einem gepflegtem GL-Treiber wie dem von nVidia der unnötige Ballast (Overhead) auf der CPU-Seite nochmals verringert werden konnte.

Zwar nicht in dem Maß wie bei AMD, da aber deren OGL-Windows-Treiber eigentlich seit Jahren nur noch eine Frechheit ist, ist natürlich bei AMD der Gewinn um so größer.

[aufkrawall]

Wobei man noch dazu sagen muss, dass Nvidia OGL im CPU-Limit offenbar langsamer bei dem Spiel ist als RadeonSI (siehe bessere Nvidia-Performance in 1440p):
https://www.phoronix.com/scan.php?page=article&item=1080p-1440p-rtx2060&num=5

[Ätznatron]

Was hindert AMD eigentlich, genau so mit dem Windows-Treiber zu verfahren wie mit dem RadeonSI? Also AMDs hauseigene open source Entwickler + Unterstützung der Community zeigen doch, dass da was Ordentliches auf die Beine gestellt werden kann.

Alles nur wegen Windows closed source?

[iuno]

Es ist ihnen einfach den Aufwand nicht wert. Mesa und Gallium sind nunmal fuer Linux/DRI gebaut. Dazu hat man sich in Mesa lange compatibility profiles verweigert, die legacy "Profi"-Software oft braucht. Deshalb zieht man ja im "pro" Stack auch bis heute noch den schrottigen closed OGL Treiber auf Linux mit.

Ausserdem hat AMD eine Plattformuebergreifende Abstraktionsschicht. Wenn ein einzelner Treiber die ausnahmsweise nicht benutzt, ist es wieder mehr Aufwand.

[Badesalz]

Wegen der Diskussion hier vor einem Jahr, aus dem bereits ausstudierten :) Uniumfeld (an der Uni beschäftigt) vor paar Wochen mitbekommen.
Das gleiche "Problem" mit:
OpenCL 1.2 = 1, Vulkan knapp +10%, OpenCL 2 knapp +30%.

2018. Keine Ahnung welche Versionen/Platformen. Ist nicht so meins. Ich war eher der passive Zuhörer.
Cuda für recht ok befunden, aber doch stinkig wegen deren OpenCL 2 Rauchgranaten.
OpenCL C(++) für wunderbar befunden (gegenüber anderen Lösungsansätzen, außerhalb von Cuda)

edit:
Bin verstört :freak: ;) Dafür braucht man kein Metal machen. Oder was los da?
https://www.youtube.com/watch?v=TWVSL_v16hQ

[aufkrawall]

Der führende AMD-Mitarbeiter zur Verbesserung von LLVM hat das Handtuch geworfen und ist nach Unity gewechselt.
Valve hingegen hat einen eigenen Shadercompiler für RADV entwickelt, der schon jetzt im frühen Stadium schneller ist :freak: :
https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200

Es sei noch mal gesagt, dass der auf LLVM basierende Compiler für amdvlk (open) immer noch eklatant langsamer kompiliert als mainline LLVM, der auch schon wiederum eklatant länger braucht als der closed source. :freak:

[iuno]

Dort wird gut die Haelfte der compile Zeit angegeben, und das waehrend nur Compute- und Fragmentshader von ACO kompiliert werden, der Rest noch von LLVM.

Aber sind compile Zeiten mit Vulkan ueberhaupt noch ein Problem?

Mal schauen, was es fuer eine Auswirkung hat. AMD koennte jetzt mit amdvlk noch mehr als ohnehin schon unter Druck geraten. Ich habe keine Ahnung, welches Potenzial es fuer LLVM und die closed Toolchain noch gibt, aber ich bin gespannt ;)

edit: Ergebnisse sind hier: https://gist.github.com/pendingchaos/aba1e4c238cf039d17089f29a8c6aa63
Demnach ist der Graph schmeichelhaft, da fehlt das Ergebnis von amdgpu-pro, was im Kompilieren fast nochmal doppelt so schnell ist wie ACO

[aufkrawall]

Aber sind compile Zeiten mit Vulkan ueberhaupt noch ein Problem?

Ich würde jetzt laienhaft mal behaupten: Mehr als mit DX11/OGL, weil die Entwickler stärker drauf achten müssen, dass die Shader rechtzeitig kompiliert sind. Deswegen hatten oder haben ja auch viele expl. API-Implementierungen mit dem Shader Compile Stottern zu kämpfen. Und natürlich trifft das auf DXVK/D9VK (oder andere Wrapper) komplett zu, die ohne gefüllten State Cache um so schlimmer stottern, je langsamer das Kompilieren ist. das Problem hat Gallium Nine als State Tracker ja gar nicht. RadeonSI/GL kompiliert auch wesentlich schneller als RADV, stockt also viel weniger stark.

[danarcho]

Sieht so aus als wär die Katze jetzt aus dem Sack :)

[iuno]

:up:

Ich wollt's gleich mal antesten, ist ja schon ein PKGBUILD im aur, einfacher geht's nicht. Dann gemerkt dass ich kein aktuelles Spiel auf Steam habe. Dementsprechend wird das mit meiner Bandbreite erstmal vertagt :usad:

[pixeljetstream]

Ich würde jetzt laienhaft mal behaupten: Mehr als mit DX11/OGL, weil die Entwickler stärker drauf achten müssen, dass die Shader rechtzeitig kompiliert sind. Deswegen hatten oder haben ja auch viele expl. API-Implementierungen mit dem Shader Compile Stottern zu kämpfen.

Genau der richtige Umgang beim shader/pso erstellen ist leider in vielen Programmen nicht optimal gelöst. Viele der dx12 stutter lassen sich auch darauf zurückführen. Bei den alten apis isses halt okay für Treiber das im Hintergrund zu machen.

[aufkrawall]

Genau der richtige Umgang beim shader/pso erstellen ist leider in vielen Programmen nicht optimal gelöst. Viele der dx12 stutter lassen sich auch darauf zurückführen. Bei den alten apis isses halt okay für Treiber das im Hintergrund zu machen.
Kann sein, dass Ressourcen-Verwaltung eine zweite Problemquelle ist?

Zu radv aoc: Ist in Doom definitiv viel schneller als mainline-radv mit llvm, das hatte nur ca. radeonsi-Performance erreicht. Jetzt erreicht das wohl amdvlk-llvm-Performance, wenn nicht mehr. Auch die Partikel-Physik funktioniert im Gegensatz zu llvm richtig. Das lässt für Doom Eternal hoffen. Vielleicht überholt man ja auch schon bald amdvlk-closed. :freak:

Falls jetzt Stadia auch auf radv-aoc setzt, kann man AMDs amdvlk-Strategie wohl als ziemlich gescheitert ansehen.

Edit: Kurzer Benchmark von mir: Mal eben 22% schneller, obwohl noch gar nicht für alle Shader genutzt :freak: :
https://abload.de/thumb/screenshot_20190704_1npkc1.png (https://abload.de/image.php?img=screenshot_20190704_1npkc1.png) https://abload.de/thumb/screenshot_20190704_1ybjjd.png (https://abload.de/image.php?img=screenshot_20190704_1ybjjd.png)

Btw: Steam-Overlay kommt auch nicht mit den Frames aus der Compute Queue klar, erst mit abgeschaltetem Async Compute (FXAA=an) geht es.
Die Partikel sind mittlerweile offenbar doch auch in LLVM selbst (oder im Treiber) gefixt.

[gravitationsfeld]

AMDGPU-PRO ist immer noch ein bisschen schneller als ACO, aber ich erwarte, dass sich das schnell schliesst.

[danarcho]

Falls jetzt Stadia auch auf radv-aoc setzt, kann man AMDs amdvlk-Strategie wohl als ziemlich gescheitert ansehen.
Ich würde das zumindest mittelfristig nicht erwarten... Naja, auf der anderen Seite haben die nur ausgewählte Spiele, was es zumindest Leicht machen würde, auf Bugs zu testen... who knows.

Kurzer Benchmark von mir: Mal eben 22% schneller, obwohl noch gar nicht für alle Shader genutzt :freak: :
AMDGPU-PRO ist immer noch ein bisschen schneller als ACO, aber ich erwarte, dass sich das schnell schliesst.
@gravitationsfeld: Jetzt wäre ich mal interessiert, ob VS/TS noch irgendwas reißen könnte? Klar, es gibt noch so ein paar Kleinigkeiten, die wir machen können, aber die Luft bei den Optimierungen wird schon dünner (wir haben bei Doom ~5% geringere code size als LLVM). Die AMDVLK-Treiber und auch der Windows-Treiber benutzen Game-spezifische Profile, die, wenn ich mich richtig erinnere, bei Doom fast 10% Performance ausmachen.

[gravitationsfeld]

Was ist VS/TS?

[danarcho]

Vertex & Tesselation Shader. Die Frage ist, wie viel GPU-Zeit die ca. beanspruchen. Ich denke mal, Pixel und Compute Shader machen den großteil aus, aber wenn die anderen trotzdem auf 20-30% kommen, dann dürfte da noch ein bisschen rauszuholen sein.

[gravitationsfeld]

Wir benutzen keine Tesselation.

[danarcho]

Oh, daher also die gute performance :)
Naja, ich denke mal VS dürfte kaum an GPU-Zeit beanspruchen, wenn Partikel und der ganze Kleinkram durch CS berechnet werden.

[gravitationsfeld]

Oh, daher also die gute performance
Das ist nur ein kleiner Teil des Puzzles.

[bnoob]

https://www.collabora.com/news-and-blog/news-and-events/moving-the-linux-desktop-to-another-reality.html

The first step into this direction was to make the window manager stop extending the desktop. With his work on drm leasing, Keith Packard introduced a non-desktop property for X11 displays. A Vulkan VK_EXT_acquire_xlib_display extension was specified, intended to be used by VR compositors to enable rendering to HMDs directly. An equivalent extension is currently being introduced for Wayland and implemented into the graphics stack.

With the first step being completed, the Linux graphics stack was aware of HMDs, and VR runtimes like SteamVR or Monado were now able to render in direct mode, without the necessity of opening a window visible to the window manager and uncertainties about HMD refresh rate being synchronized with the desktop displays.

But this also meant desktop windows were no longer showing up on the HMD. It was time to bring them back, fully rendered, and in 3D.

Today, we are very excited to announce a new open source project which enables interaction with traditional desktop environments, such as GNOME and KDE, in VR. Sponsored by Valve, xrdesktop makes window managers aware of VR and is able to use VR runtimes to render desktop windows in 3D space, with the ability of manipulating them with VR controllers and generating mouse and keyboard input from VR.

[iuno]

OpenGL hat aber in dem Sinne die gleichen Probleme wie Vulkan. Bei einem top-aktuellen macOS kriegst du nur OpenGL 4.1. Daran wird sich vermutlich auch ne Weile nichts ändern, da Apple jetzt an ihrem Metal und ihrem WebGPU Kram bastelt.
Ich wusste doch, dass WebGPU irgendwo im Forum schonmal Thema war ;p

Da es nirgends besser rein passt: das W3 Konsortium erwaegt, SPIR-V als shading language fuer WebGPU (WebGL Nachfolge).

Dort ist das nur eine Randnotiz, aber trotzdem: https://www.w3.org/blog/2019/11/status-update-on-web-games-technologies/

[dildo4u]

Vulkan Memory Allocator 2.3.0


VMA (Vulkan Memory Allocator) is our single-header, MIT-licensed, C++ library for easily and efficiently managing memory allocation for your Vulkan® games and applications. One year after our previous release, we are publishing a new version. You can get it now by going to VulkanMemoryAllocator Releases on GitHub and grabbing the latest v2.3.0.

Many things have happened throughout this past year. In March, we conducted a survey among developers, which gave us a good understanding on how the project is being used. We learned which of the existing features are important, which ones… not so much, and which ones aren’t there but are very much needed. This allowed to prepare our internal roadmap for future development.

The library was also used in many projects – open source code on GitHub, some AAA games, and even official Khronos® Group Vulkan Samples. VMA is used on all kinds of platforms, from mobile SOC, through desktop, to cloud gaming. Many users reported bugs, suggestions for improvements, questions, and other contributions.

During this time the library had continuous development on the “master” branch and special feature branches, so if you were using the latest code, the list of new features won’t be a surprise to you. Otherwise, here is a brief list of notable changes since previous version 2.2.0:

Added support for Vulkan 1.1 (Vulkan 1.0 may still be used).
Added support for query for memory budget and staying within the budget with optional use of VK_EXT_memory_budget extension.
Added support for VK_KHR_bind_memory2 extension.
https://gpuopen.com/vulkan-memory-allocator-2-3-0/

[aufkrawall]

On Nvidia, D3D11 tends to work a lot better in CPU-bound scenarios (as it should, since we're doing quite a bit of extra work that a native driver doesn't need to care about), and at the same time, their Vulkan driver also seems to have some drawbacks. There are some weird performance issues that are not specific to DXVK, i.e. some workloads just perform worse with Vulkan than with D3D11 no matter how hard you optimize the Vulkan path. Older architectures such as Kepler are especially bad and only reach ~50% of native performance.
https://www.gamingonlinux.com/articles/dxvk-15-released-with-d9vk-merged-in-for-d3d9-support-plus-a-statement-on-dxvks-future.15613/comment_id=171047
Expl. API scheint einfach inkompatibel zu deren Firmen-DNA zu sein. :freak:

[][immy]

https://www.gamingonlinux.com/articles/dxvk-15-released-with-d9vk-merged-in-for-d3d9-support-plus-a-statement-on-dxvks-future.15613/comment_id=171047
Expl. API scheint einfach inkompatibel zu deren Firmen-DNA zu sein. :freak:
Tja, eventuell hat nvidia im Treiber einfach ein paar zu gute Optimierungen :freak:

Nur weil man mehr Kontrolle über die Hardware nehmen muss, heißt das ja nicht, das man etwas besser macht als nvidia. Eventuell hat nvidia auch ein paar Abkürzungen in Hardware gegossen die so erst mal nicht verwendet werden können mit den neueren APIs.

Aber schön zu erfahren, das es nicht an DX12 selbst liegt sondern wohl tatsächlich was mit der Hardware oder irgendwelche Optimierungen zu tun hat.

[Ätznatron]

Die Vulkan-Portierung vom Flusi X-Plane schreitet derweil voran, und das mit offenbar sehr guten Ergebnissen die FPS und das "Ruckeln" betreffend.

FPS-Analyse:

EDDL (Flughafen Düsseldorf)


https://forums.x-plane.org/uploads/monthly_2020_01/eddl.thumb.PNG.fef6650bc4e1ac9a98756e23ac4f2ca0.PNG

KSEA (Seattle-Tacoma International Airport)

https://forums.x-plane.org/uploads/monthly_2020_01/ksea.thumb.PNG.8df190500e54f040df7767e6d388c109.PNG

(https://forums.x-plane.org/index.php?/forums/topic/198344-x-plane-1150/&do=findComment&comment=1812236)

Sowohl nVidia als auch, und vorallem, AMD profitieren deutlich vom Vulkan-Port.

X-Plane dürfte für AMD-Kartenbesitzer jetzt erstmalig überhaupt vernünftig spielbar werden bei etwas anspruchsvolleren Settings. OMG, was ist AMDs OGL-Treiber doch für ein Schrott.

[Unicous]

Vulkan 1.2 Specification Released: Refining For Efficiency & Development Simplicity (https://www.anandtech.com/show/15401/vulkan-12-specification-released)

[pixeljetstream]

Passende Treiber zu 1.2
https://developer.nvidia.com/vulkan-driver

[gravitationsfeld]

https://www.gamingonlinux.com/articles/dxvk-15-released-with-d9vk-merged-in-for-d3d9-support-plus-a-statement-on-dxvks-future.15613/comment_id=171047
Expl. API scheint einfach inkompatibel zu deren Firmen-DNA zu sein. :freak:
Sind auch Hardware-Probleme. Vor allem bei Kepler.

[Unicous]

AMD-Treiber:

https://www.amd.com/en/support/kb/release-notes/rn-rad-win-20-1-2

[TheAntitheist]

https://www.gamingonlinux.com/articles/dxvk-15-released-with-d9vk-merged-in-for-d3d9-support-plus-a-statement-on-dxvks-future.15613/comment_id=171047
Expl. API scheint einfach inkompatibel zu deren Firmen-DNA zu sein. :freak:
eigentlich sollte es heissen "no matter how hard you optimize, you won't optimize as hard as nvidia is able to"

weil Nvidia optimiert ja auch nur per software...

[dildo4u]

Bringing HLSL Ray Tracing to Vulkan

The NVIDIA VKRay extension, with the DXC compiler and SPIR-V backend, provides the same level of ray tracing functionality in Vulkan through HLSL as is currently available in DXR. You can now develop ray-tracing applications using DXR or NVIDIA VKRay with minimized shader re-writing to deploy to either the DirectX or Vulkan APIs.

We encourage you to take advantage of this new flexibility and expand your user base by bringing ray tracing titles to Vulkan.

https://devblogs.nvidia.com/bringing-hlsl-ray-tracing-to-vulkan/

[aufkrawall]

Unglaublich: In SS Fusion deklassiert Vulkan nun D3D11 um 20%, und das auf Pascal:

D3D11:
https://abload.de/thumb/sam2017_2020_03_01_12a9jxr.png (https://abload.de/image.php?img=sam2017_2020_03_01_12a9jxr.png)

D3D12:
https://abload.de/thumb/sam2017_2020_03_01_12esjsn.png (https://abload.de/image.php?img=sam2017_2020_03_01_12esjsn.png)

Vulkan:
https://abload.de/thumb/sam2017_2020_03_01_1295jeq.png (https://abload.de/image.php?img=sam2017_2020_03_01_1295jeq.png)

Leider hat expl. API bei dem Spiel immer noch Shader Compile Stutter.

[iuno]

Ist eigentlich bekannt, warum bei AMD der VRAM pool, der host visible (und concurrent) ist, auf 256M beschraenkt ist?

Ich habe jetzt selbst keine da, aber so wie ich das sehe, ist das sogar bei den APUs der Fall?! Wohingegen bei Intel beide Heaps alle flags haben.

Auf GPUOpen (https://gpuopen.com/vulkan-device-memory/) steht was von einem Windows limit, ist aber bei Linux mit RADV als auch AMDVLK genauso der Fall. Das waere doch ein Vorteil, wenn APUs den gesamten RAM so nutzen koennten, womit man sich die Transfers sparen koennte oder uebersehe ich was?

[SaschaW]

Das trifft nur auf einen speziellen Typ zu der auf diesem max. 256 MByte großem Heap basiert. Dabei handelt es sich um einen Speichertyp der zusätzlich die Eigenschaft "Device local" besitzt, also VRAM der direkt in den Adressraum des Hosts gemappt ist. Der ist perfekt für den Upload von Daten von CPU zu GPU geeignet, weil das am PCIe vorbei geht.

Es gibt auch andere Memory Types die für den Host sichtbar und kohärent sind (wie z.B. bei NV und Co.) mit denen man auf den ganzen VRAM zugreifen kann. Der obige Typ erspart dir halt z.B. das Stagen und Kopieren.

[pixeljetstream]

Die Frage ist glaube ich eher woher die 256 MB kommen. HW oder SW Limit.

[iuno]

Ja, genau. Ich dachte dadurch dass ich VRAM schrieb, impliziere ich device_local und habe das nicht extra dazugeschrieben.

Was meinst du mit „am PCIe vorbei“? Da muss es doch so oder so durch, vorbei geht es da halt am RAM?

[pixeljetstream]

hab mal nachgeschaut, wenn ich es richtig verstanden habe, wird die Größe des so direkt adressierbaren Speichers im VBIOS festgehalten und ist Teil des PCI-E setups.
https://en.wikipedia.org/wiki/PCI_configuration_space

Wenn du "host visible SYSRAM" speicher nimmst, und dann die GPU darauf zugreift, muss halt das memory & caching system möglichst gut sein um zu verhindern, dass Du oft die Daten über den bus holst. Sowas wie random access über einen großen Bereich wäre dann ziemlich schlecht. Aber für "one-time" use, insbesondere wenn relativ linear, oder wenn die daten im cache gehalten werden, ist's ausreichend. Wie Sascha erwähnte ist für die meisten Ressourcen, weil sie mehrfach verwendet werden, der Weg sie einmal in VRAM zu kopieren.

Beim "host visible VRAM", hast du weniger Probleme bei random access, aber hast halt die Größeneinschränkung und musst auch beim Schreiben der Daten sorgfältiger sein.

[iuno]

Danke fuers Nachsehen. D.h. die 256M sind einfach nur im VBIOS so hinterlegt? Dann verstehe ich aber auch nicht, warum man hier diese Grenze gewaehlt hat. Prinzipiell sollte das ja auf dem kompletten Bereich moeglich sein?

Ja, dass es mit sysram lahm waere, ist klar.

[gravitationsfeld]

Mir hat AMD mal erzaehlt, dass das OS das eigentlich aendern koennte, Windows es aber nicht macht. Ist eigentlich gaga, dass man im 64-Bit-Zeitalter nicht einfach den ganzen VRAM mappen kann.

[pixeljetstream]

Ich mag nicht ausschließen, dass die Zahlen im vbios viel größer sind als das was das Windows OS nutzt, es ist nicht die Ecke des Treibers womit ich mich sonst beschäftige, oder aber die Implementierung bei AMD ist halt komplett anders. Unter der Woche kann ich Mal die passenden Leute fragen.

[gravitationsfeld]

Anscheinend muesste da Microsoft was dran aendern. Aber ich koennte mich auch komplett taeuschen.

[danarcho]

Ich habe jetzt selbst keine da, aber so wie ich das sehe, ist das sogar bei den APUs der Fall?! Wohingegen bei Intel beide Heaps alle flags haben.

Auf GPUOpen (https://gpuopen.com/vulkan-device-memory/) steht was von einem Windows limit, ist aber bei Linux mit RADV als auch AMDVLK genauso der Fall. Das waere doch ein Vorteil, wenn APUs den gesamten RAM so nutzen koennten, womit man sich die Transfers sparen koennte oder uebersehe ich was?
Nein, unter RADV haben beide Heaps alle Flags.

VkPhysicalDeviceMemoryProperties:
=================================
memoryHeapCount = 2
memoryHeaps[0] :
size = 2147483648 (0x80000000) (2.00 GiB)
budget = 1960800256
usage = 0
flags:
VK_MEMORY_HEAP_DEVICE_LOCAL_BIT
memoryHeaps[1] :
size = 3221225472 (0xc0000000) (3.00 GiB)
budget = 3197931520
usage = 0
flags:
VK_MEMORY_HEAP_DEVICE_LOCAL_BIT
memoryTypeCount = 3
memoryTypes[0] :
heapIndex = 0
propertyFlags = 0x7:
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
usable for:
OPTIMAL: color images, D16_UNORM, D32_SFLOAT, S8_UINT, D16_UNORM_S8_UINT, D32_SFLOAT_S8_UINT
LINEAR: color images
memoryTypes[1] :
heapIndex = 1
propertyFlags = 0x7:
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
usable for:
OPTIMAL: color images, D16_UNORM, D32_SFLOAT, S8_UINT, D16_UNORM_S8_UINT, D32_SFLOAT_S8_UINT
LINEAR: color images
memoryTypes[2] :
heapIndex = 1
propertyFlags = 0xf:
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
VK_MEMORY_PROPERTY_HOST_CACHED_BIT
usable for:
OPTIMAL: color images, D16_UNORM, D32_SFLOAT, S8_UINT, D16_UNORM_S8_UINT, D32_SFLOAT_S8_UINT
LINEAR: color images


Bzw, die sind and den memory types. Ich frage mich, wieso man die nicht an den Heap packt...
Bei AMDVLK sieht es ähnlich aus, nur dass dort 8 verschiedene memory types mit unterschiedlichen properties aufgeführt werden, wieso auch immer.

Edit: Den 'gesamten' RAM nutzen kann man bei APUs, aber nur die im BIOS zugewiesenen 1-2 GB sind schnell. Ich bin mir nicht sicher, woran das liegt, vermute aber es hat irgendwas mit der address translation table in der GPU zu tun.

[pixeljetstream]

Anscheinend muesste da Microsoft was dran aendern. Aber ich koennte mich auch komplett taeuschen.

bin mal bissl durch den linux treiber gegangen, wo für AMD ja auch 256 MB gemeldet werden. Wenn man hier https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/radeon nach "visible_vram_size" sucht (was radv etc. mehr oder weniger 1:1 nutzen, gab dort ein cap auf 256 je nach versionsnummer weil vorher buggy), findet man auch Zuweisungen die auf pci configuration beruhen, zumindest sieht es für mich so aus.

[iuno]

Anscheinend muesste da Microsoft was dran aendern. Aber ich koennte mich auch komplett taeuschen.
Wie gesagt, bei Linux habe ich auch nur 256 MiB.

Nein, unter RADV haben beide Heaps alle Flags.
Bei mir nicht (Mesa 19.3.4, Linux 5.5.8 Polaris 10). Die Info, bei APUs sei es gleich, hatte ich irgendwo gelesen und bei gpuinfo.org nachgeschaut, in diesem Fall falsch. Welche APU hast du?
Dann klaert sich die Frage damit, wenn das Limit bei APUs weg ist.

edit: vielleicht war es hier (http://twvideo01.ubm-us.net/o1/vault/gdc2018/presentations/Sawicki_Adam_Memory%20management%20in%20Vulkan.pdf), Seite 19. Dort steht zwar, dass der ganze Speicher unified ist, aber man halt trotzdem diese komische Partitionierung hat.

Danke fuer die Antworten :up:

[danarcho]

Ok, ich habe mal nachgefragt. Also, zunächst wird die Limitierung auf 256MB im BIOS festgelegt und liegt vor allem daran, dass dort meist physisch bei PCIe mit 32bit gearbeitet wird. Und da bei 32bit der address space wertvoll ist, limitiert man den gemapten Bereich auf 256MB. Neuere Chipsets/BIOS, die mehr als 4GB alloziieren können, mappen auch den gesamten VRAM, was dann auch bei RADV genutzt werden kann. Mir werden aber auch mit Z370 chipset nur 256MB angezeigt, also keine Ahnung wie neu jetzt neu heißt.

Ich habe mehrere APUs, aber nachgeschaut hatte ich vorhin auf meinem Raven Laptop.

Edit: also 'neu' heißt wohl eher workstation/server chipsets in dem Zusammenhang. Und warum bei APUs der restliche RAM langsamer ist, weiß irgendwie keiner.

[iuno]

Danke fuer die Aufklaerung :up:


Eine Frage stellt sich mir noch, wo ich gerade etwas mit Vulkan "spiele", auch wenn ich die Antwort schon zu kennen glaube: eine Art Zero-copy staging Buffer bekomme ich nicht hin oder? Also von der Ausgangslage, dass Daten schon von woanders im sysram sind, jetzt aber von der GPU bearbeitet werden sollen. Dann muss ich zwingend erst nochmal von sysram zu sysram (staging buffer) kopieren, bevor es dann in den VRAM kann?

[pixeljetstream]

Genau du kannst im core keinen bestehenden sysram Pointer direkt nehmen.

Es gibt allerdings
https://github.com/KhronosGroup/Vulkan-Docs/blob/master/appendices/VK_EXT_external_memory_host.txt

[aufkrawall]

Mag jemand die praktischen Implikationen einmal knapp zusammenfassen und ggf. die Unterschiede zu Intel aufzeigen?

[iuno]

@pixeljetstream: ist glaube ich genau, was ich gesucht habe. Danke, schaue ich mir spaeter mal an.
@aufkrawall: Gibt keine Unterschiede, wie man an danarchos output mit APU sieht.

Man kann in Vulkan verschiedene Speicherheaps und dazugehoerige -typen benutzen. Die bietet das Geraet bzw. der Treiber an und haben verschiedene Eigenschaften, die man abfragen kann, um den "richtigen" Speichertyp fuer sich auswaehlen zu koennen. Z.B. device_local (=VRAM, schnell) oder host_visible (laesst sich im CPU Adressraum mappen).
Normalerweise kriegt man Daten in den VRAM, indem man einen zusaetlzichen staging buffer in einem memory type, der host_visible ist, anlegt. Dort die Daten reinkopiert und dann einen Transfer in einen buffer macht, der device_local ist.
APUs und Intel IGPs haben allerdings auf allen memory types host_visible und device_local, d.h. man kann sich das mit dem staging buffer sparen und direkt in den "VRAM" schreiben. AMD dGPUs haben so einen Speichertyp auch (d.h. man kann VRAM im CPU Addressraum mappen und schreibt dann ohne weiteres Zutun ueber PCIe dort hinein), aber der ist idR. (s.o.) auf 256 MiB begrenzt.

Spielt denke ich keine besondere Rolle, aber es waere fuer einen Laien wie mich zum Loslegen halt einfacher, man koennte sich den Zwischenschritt sparen. In meiner Testapp wuerde es ausserdem die Latenz verringern, weil einfach nur was geladen und berechnet wird, wohingegen bei Echtzeitgrafik (oder ernsthaftem GPGPU) man ja die Daten rein streamen kann, waehrend die GPU arbeitet.

[gravitationsfeld]

Mag jemand die praktischen Implikationen einmal knapp zusammenfassen und ggf. die Unterschiede zu Intel aufzeigen?
Bei Intel ist immer alles der selbe Speicher, egal ob CPU oder GPU. Es gibt keine PCIe aperture.

[aufkrawall]

@aufkrawall: Gibt keine Unterschiede, wie man an danarchos output mit APU sieht.

Thx für die Erläuterung!

[Troyan]

Khronos Gruppe hat für Vulkan nun auch "Raytracing" spezifiziert und standardisiert: https://www.khronos.org/news/press/khronos-group-releases-vulkan-ray-tracing

[pixeljetstream]

blog post dazu
https://www.khronos.org/blog/ray-tracing-in-vulkan

Das feature-set entspricht weitestgehend DXR 1.1 wobei die spec noch nicht finalisiert ist. Also nur für beta treiber, non-production use.
Unsere beta treiber werden auch über die Zeit dann einzelne feature dazu bekommen. Aber im Prinzip wollen wir alles unterstützen, nur das Bauen auf CPU ist eher unwahrscheinlich so far.

https://www.khronos.org/assets/uploads/blogs/2020-blog-raytracing-img-07.png

und wir haben in dem Zuge auch die device generated commands extension überarbeitet (leider bisher nix aus Standardisierung geworden, aber ich glaube noch an den Auswärtssieg irgendwann)
https://devblogs.nvidia.com/new-vulkan-device-generated-commands/

Mit der extension und fully bindless rücken rasterization und rayracing näher zusammen

https://raw.githubusercontent.com/nvpro-samples/vk_device_generated_cmds/master/doc/unified.PNG

wenn die digital GTC Sachen rauskommen gibt's zu diesen topics Vortrag von mir wo die Illustrationen animiert aufgebaut und erklärt werden.

[pixeljetstream]

aja der vorher diskutierte "host visible device local" Vulkan Speichertyp ist nun auch bei NVIDIA verfügbar (im beta treiber mit den anderen neuen Sachen).

[JVC]

Ist ja gut wenn sie es auch verwenden :)
Hauptsache sie "schmücken" sich nicht damit...

M.f.G. JVC

[iuno]

@pixeljetstream: danke fuer die Info. Ich habe nichts von Nvidia da, wie ist das dort geloest? Gibt es auch eine Groessenbeschraenkung und gibt's Infos wann/wie man das besser (nicht) benutzt? Bei AMD ist z.B. der host-lesende Zugriff dort besonders lahm. Ich nehme an, das ist aehnlich, einfach weil diese Art von Zugriff nicht gecacht ist?

[pixeljetstream]

@pixeljetstream: danke fuer die Info. Ich habe nichts von Nvidia da, wie ist das dort geloest? Gibt es auch eine Groessenbeschraenkung und gibt's Infos wann/wie man das besser (nicht) benutzt? Bei AMD ist z.B. der host-lesende Zugriff dort besonders lahm. Ich nehme an, das ist aehnlich, einfach weil diese Art von Zugriff nicht gecacht ist?

Der Zugriff kann schon gecached sein, je nach dem welcher Ressourcen Typ den Zugriff macht (ubo, ssbo ...). Es ist bei uns daher nicht super lahm, liegt mehr am Access pattern. Die Gewinne sind so im einstelligen Prozentbereich mit Ausnahmen auch mal 10. Ich werde vermutlich irgendwann nen Blog über das schreiben. Auch wenn es um out of Memory handling geht. Aber hab erstmal anderes zu tun. Ich vermute wir exposen auch die 256 MB. Guck später nach

edit: 257,949,696 bytes http://vulkan.gpuinfo.org/displayreport.php?id=8119#memoryheaps

[pixeljetstream]

GTC 2020 Vortrag zu Vulkan 1.2, Ray Tracing und Generated Commands. Wer sich meine mms und eehs antun will ;) gibt viele Bildchen und Illustrationen

https://developer.nvidia.com/gtc/2020/video/s21770

[Ätznatron]

So, Vulkan hat es jetzt endlich in die erste öffentliche Beta 10.50b1 (https://developer.x-plane.com/2020/04/x-plane-11-50-public-beta-1-vulkan-and-metal-are-here/) von X-Plane 11 (https://www.x-plane.com/)geschafft.

Ich bin gerade dabei, die Auswirkungen auf die FPS zu testen, kann aber jetzt schon sagen, dass meine Radeon VII um mindestens 100% höhere Frameraten schafft, als vorher mit dem OGL-Treiber. Generell soll diese Leistungssteigerung alle AMD-Karten betreffen.

Laut diverser Forenbeiträge (https://forums.x-plane.org/index.php?/forums/forum/437-xp1150-beta/) profitieren nVidia-Karten immerhin noch mit bis zu 30% Mehrleistung.

[pixeljetstream]

ja man sieht, dass die Vulkan-Train richtig an Fahrt nun aufnimmt. Auch im Profi Markt der noch stark an GL hängt merkt man den Umbruch, auch wenn es dauert bis es in Produkten ist. Metal hilft hier auch stark weil nun viele gezwungen sind zu modernisieren.

[Schnäppchenjäger]

GTC 2020 Vortrag zu Vulkan 1.2, Ray Tracing und Generated Commands. Wer sich meine mms und eehs antun will ;) gibt viele Bildchen und Illustrationen

https://developer.nvidia.com/gtc/2020/video/s21770Du bist Christoph Kubisch, der Presenter der da gelistet wurde? :eek:
Krass, also arbeitest du bei Nvidia? :eek:

[pixeljetstream]

Du bist Christoph Kubisch, der Presenter der da gelistet wurde? :eek:
Krass, also arbeitest du bei Nvidia? :eek:
Ist auch indirekt dem Profil und Signatur entnehmbar, wobei man die beim mobile Client vom Forum nicht sieht. Bin seit Ende 2010 dort. Krass ist eher wie die Zeit vergeht ;) gibt ja ein paar mehr die in der Industrie arbeiten hier im Forum.

Und als Erinnerung das ist ein privater Account, da gerade ein paar PMs reingehen. Ich äußere mich hier nur zu Themen der allgemeinen Computergrafik Entwicklung und dem was ich (oder andere) ohnehin öffentlich bearbeiten, bitte keine Fragen zu Bug/Feature/Treiber etc. Wie erwähnt, bitte lieber sehen als eine Person in der Industrie, nicht "Die" Person bei Hersteller XYZ.

[Schnäppchenjäger]

Ist auch indirekt dem Profil und Signatur entnehmbar, wobei man die beim mobile Client vom Forum nicht sieht. Bin seit Ende 2010 dort. Krass ist eher wie die Zeit vergeht ;) gibt ja ein paar mehr die in der Industrie arbeiten hier im ForumIst das wirklich so? Sind die meisten nicht irgendwelche SAP-Fuzzies? :freak:
Informatiker die so nah an der Hardware arbeiten kenne ich persönlich überhaupt keine... alle sind sie entweder simple Admins oder halt die besseren sind Developer, ob nun Java, C# oder sonstwas. Dann gibt es halt noch die üblichen Ausbildungen FISI und FIAE.
Frage mich echt was es da für Berufe gibt als ITler bei Nvidia... kennst du Leute die Treiber programmieren/entwerfen?
Ich fand die technischen und theoretischen Bereiche der Informatik immer am interessantesten, so aus hobbyinteressierter Sicht :)
Aber damit gibt es halt kaum Berufe, vor allem in Deutschland nicht denke ich.

[danarcho]

Da du explizit nach Treiber-Entwicklung fragst: Hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=595575) hast du mein coming-out. Aber eins der Probleme scheint zu sein, dass sich anscheinend leider Leute auch mal schnell wieder verabschieden, wenn ihre Identität zu breit getrampelt wird. Just saying...

Du kannst in diesem Forum aber sicherlich recht kompetente Antworten bekommen, auch ohne bei jedem zu wissen, was er beruflich macht ;)

[Schnäppchenjäger]

Da du explizit nach Treiber-Entwicklung fragst: Hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=595575) hast du mein coming-out.

Du kannst in diesem Forum aber sicherlich recht kompetente Antworten bekommen, auch ohne bei jedem zu wissen, was er beruflich macht ;)Mir ging es ja nicht um die Antworten für gewöhnliche Themen (ich gehe mal davon aus, dass sich zu 90% eh nur Leute die Ahnung haben was dazu schreiben werden), man muss ja keinen Doktor der Elektrotechnik besitzen um jemandem bei seinem WLAN-Problem behilflich zu sein :wink:
Du bist ja auch nicht pixeljetstream und trotzdem hat dein Beitrag Sinn ergeben und den Thread bereichert :biggrin:
Es ist halt etwas anderes, wenn jemand selbst bei der Entwicklung von APIs involviert ist und Einblicke hat, die ein normalsterblicher Hobbylaie nie und nimmer haben kann.
Sehr netter Link übrigens, muss ich mir beizeiten mal reinhämmern :cool:
Aber eins der Probleme scheint zu sein, dass sich anscheinend leider Leute auch mal schnell wieder verabschieden, wenn ihre Identität zu breit getrampelt wird. Just saying...Das ist natürlich schade, Anonymität will ja (mehr oder minder) gewahrt werden.

[Ex3cut3r]

Mal ein Lob an pixeljetstream :up:
Finde er versuchte immer die richtigen Infos rauszuhauen, und auch viel Geduld mit uns DAUs.

[Raff]

GTC 2020 Vortrag zu Vulkan 1.2, Ray Tracing und Generated Commands. Wer sich meine mms und eehs antun will ;) gibt viele Bildchen und Illustrationen

https://developer.nvidia.com/gtc/2020/video/s21770

Danke dafür. :up:

Ein paar Fragen und Gedanken dazu:

1.) KHR_Raytracing ist also die Evolution von NV_Raytracing, sodass Nvidia die Khronos-Extension empfiehlt. Das heißt, dass Nvidia die eigene, alte Extension nun sterben lässt? Oder wird man hier im Laufe der Zeit "Extensions der Extension" einführen?
2.) Da KHR eine andere Syntax verwendet als NV, wird man wohl keine simplen Ports von einem auf das andere sehen, richtig? Also beispielsweise für Quake II RTX oder Wolfenstein Youngblood.
3.) An welcher Stelle wird eigentlich entschieden, dass vorhandene Hardware-Einheiten das Traversal übernehmen?
4.) Kann man irgendwie seiner RTX-Karte verbieten, die Hardware herzunehmen und stattdessen Software-Raytracing à la Turing Light betreiben?
5.) Weißt du, wann der erste GRD mit Vulkan 1.2 erscheint? Derzeit sind das ja alles noch Dev-Branches.

MfG
Raff

[pixeljetstream]

Danke dafür. :up:

Ein paar Fragen und Gedanken dazu:

1.) KHR_Raytracing ist also die Evolution von NV_Raytracing, sodass Nvidia die Khronos-Extension empfiehlt. Das heißt, dass Nvidia die eigene, alte Extension nun sterben lässt? Oder wird man hier im Laufe der Zeit "Extensions der Extension" einführen?
2.) Da KHR eine andere Syntax verwendet als NV, wird man wohl keine simplen Ports von einem auf das andere sehen, richtig? Also beispielsweise für Quake II RTX oder Wolfenstein Youngblood.
3.) An welcher Stelle wird eigentlich entschieden, dass vorhandene Hardware-Einheiten das Traversal übernehmen?
4.) Kann man irgendwie seiner RTX-Karte verbieten, die Hardware herzunehmen und stattdessen Software-Raytracing à la Turing Light betreiben?
5.) Weißt du, wann der erste GRD mit Vulkan 1.2 erscheint? Derzeit sind das ja alles noch Dev-Branches.

MfG
Raff

1) khr ist ein superset an Features, allein deswegen macht es Sinn es zu nehmen. Und da Ray Tracing ja nicht am Ende ist, wird es neue Features dann eher on top of khr geben. Entfernen tun wir die NV nicht, im Treiber ist ja beides gleich, am Ende landet eh alles in dem raytracing Backend was für dx12, vk, optix7 gleich ist. NV ist auch das einzige was im Moment production ready ist.

2) imo ist der Portierungsaufwand sehr gering und könnte von nem wrapper erledigt werden. Da quake 2 rtx ja open-source ist, denke wird sehr fix passieren.

3 & 4) Du kannst das nicht beeinflussen, Die RT cores werden immer benutzt. Wenn man wissen will was sie bringen dann halt mit 1660 oder gv100 vergleichen. Oder auf der gleichen Hardware zum Beispiel optimierte offline raytracsr die optix7 vs eigene cuda Implementierung vergleichen. (Es gibt ja einige kommerzielle Produkte)

5) khr ist "provisional", nicht fertig da das Design sich noch leicht ändern könnte. Aus Khronossicht kann eine spec auch dann nicht fertig sein wenn es nur eine Implementierung (im Moment von NV) gibt. Solange sich die API noch ändern kann, macht es keinen Sinn sie in production driver zu geben. Das Ziel sind im Moment Entwickler und deren Feedback. Auch in Vulkan selbst sind die neuen Funktionen extra in nem beta header um klar zu machen dass es noch keine Garantie für zukünftige Kompatibilität gibt. Man lernt bissl aus der Vergangenheit, da von 1.0 bis 1.2 immer wieder Kleinkram gefixed wurde den man mit beta Phase wohl erwischt hätte.
Khronos hat keine Timeline angegeben wann es fertig sein wird. Ratifiziert ist das Provisorium aber schon, das heißt der rechtliche Rahmen (Patente etc.) ist gegeben.

[Raff]

Ich danke dir für deine Ausführungen. :up:

Wie oft kommt es eigentlich vor, dass Vendor-Extensions von den Mitbewerbern benutzt werden? Oder anders gefragt: Wie wahrscheinlich ist es, dass man mit einer Radeon-GPU gegen Ende des Jahres die bestehenden Vulkan-Spiele mit Raytracing wird verwenden können?

Schade, dass man den Software-Fallback, der ja vollumfänglich im Treiber steckt, nicht auch auf Turing RTX forcieren kann. Das gäbe interessante Vorher-Nachher-Messungen mit dicken Speedups. :)

MfG
Raff

[danarcho]

Ich klinke mich mal mit ein :)

zu 1) Es ist doch immer noch Nvidia, das wird wahrscheinlich noch in 100 Jahren unterstützt :tongue:
zu 4) Naja, bei einem Open Source Treiber kannst du das sehr einfach machen, sofern er einen software path hat. Wir sind aber noch sehr weit entfernt davon, also rechne lieber mit Ende des Jahres oder so °°
Gibt ja auch noch keine AMD Hardware zu kaufen mit RT.

Wie oft kommt es eigentlich vor, dass Vendor-Extensions von den Mitbewerbern benutzt werden? Oder anders gefragt: Wie wahrscheinlich ist es, dass man mit einer Radeon-GPU gegen Ende des Jahres die bestehenden Vulkan-Spiele mit Raytracing wird verwenden können?
Meines Wissens nach, bisher 0. Ein Problem dabei ist auch, dass Spiele oft einen per-Vendor Render-path haben, der dann gleich mehrere Vendor-spezifische Extensions verwendet, so dass die Unterstützung einer davon wenig Sinn ergibt. Vielleicht ist das bei RT aber anders. Muss ich bei Youngblood mal ausprobieren °°

[pixeljetstream]

IMO gibts durchaus vendor extensions die cross vendor implementiert wurden. Einfach bei gpuinfo.org mal unter GL gucken. In Vulkan ist das seltener, weil man nun früh die anderen Hersteller fragt ob nicht EXT gut wäre (es brauch nur zwei, dann darf man es EXT nennen), weil die Randbedingungen in vk meist schärfer sind. IMO versucht man immer EXT, Ausnahme sind halt paar Launch Features, aber danach ist auch die Diskussion da. Warum es mit EXT nicht immer klappt hat viele Gründe (keine Ressourcen, kein Druck, schwer equivalentes zu finden, schwer auf hw abbildbar, andere designphilosophie etc.). Khronos hat halt manchmal was von UN ;)

[Dampf]

Bin mal gespannt, ob sich mit diesen neuen Extensions auch was bei der Performance dreht, Wolfenstein Youngblood's RTX zieht ja dermaßen viel Leistung und das nur für RT-Reflektionen, das ist dann noch eher inakzeptabel. Glücklicherweise ist es in performantes Spiel und läuft dank DLSS auch trotzdem gut mit RTX, aber Performance-Einbußen von 50% nur für Reflektionen sind wirklich stark übertrieben, das sollte dringend optimiert werden.

[gedi]

Bin mal gespannt, ob sich mit diesen neuen Extensions auch was bei der Performance dreht, Wolfenstein Youngblood's RTX zieht ja dermaßen viel Leistung und das nur für RT-Reflektionen, das ist dann noch eher inakzeptabel. Glücklicherweise ist es in performantes Spiel und läuft dank DLSS auch trotzdem gut mit RTX, aber Performance-Einbußen von 50% nur für Reflektionen sind wirklich stark übertrieben, das sollte dringend optimiert werden.

Turing ist in Bezug auf RT auch ne Krücke (ähnlich NV40 mit DX9 FL_3.0 aka HDR). Bez. RT setze ich auf Nextgen-GPUs.

[Gast]

Bin mal gespannt, ob sich mit diesen neuen Extensions auch was bei der Performance dreht, Wolfenstein Youngblood's RTX zieht ja dermaßen viel Leistung und das nur für RT-Reflektionen, das ist dann noch eher inakzeptabel. Glücklicherweise ist es in performantes Spiel und läuft dank DLSS auch trotzdem gut mit RTX, aber Performance-Einbußen von 50% nur für Reflektionen sind wirklich stark übertrieben, das sollte dringend optimiert werden.

Control zeigt, dass einzelne Raytracing Effekte wesentlich teurer sind als mehrere zusammen in Summe.

Und ich denke aktuell ist die Leistung mit Raytracing für eine first generation verdammt gut, wenn man bedenkt wieviel Rechenleistung man damit überhaupt braucht.

[Dampf]

Turing ist in Bezug auf RT auch ne Krücke (ähnlich NV40 mit DX9 FL_3.0 aka HDR). Bez. RT setze ich auf Nextgen-GPUs.

Nö. Selbst andere Raytracing Titel zeigen wie's richtig geht. Die hervorragende GI in Metro kostet nur 20% der Performance und in Control kostet die gesamte RT-Pipeline, aka Schatten, Reflexionen und GI 45%. Nvidia hat auch eine neue Version der RTXGI SDK vorgestellt, die nochmals performanter läuft und selbst zu einer GTX 1060 runterskaliert.

Und glaube nicht dass zumindest RDNA2 Turing in Sachen RT übertreffen wird und darauf wird ja aufgrund den Konsolen zukünftig optimiert. RT wird in Zukunft immer effizienter laufen, da Engines und Entwickler gleichermaßen die Technik immer besser unterstützen und mehr mit ihr vertraut werden.

[iuno]

Mir hat AMD mal erzaehlt, dass das OS das eigentlich aendern koennte, Windows es aber nicht macht. Ist eigentlich gaga, dass man im 64-Bit-Zeitalter nicht einfach den ganzen VRAM mappen kann.
Hmm, wusste doch, dass das hier Thema war ;-)

Offenbar geht das bei Linux schon laenger, wusste ich damals auch noch nicht.

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/resizable-bar-support

https://patchwork.kernel.org/project/linux-pci/patch/20171018135821.3248-6-deathsimple@vodafone.de/

Heisst bei AMD fuer RDNA2 jetzt "Smart Access Memory" und sei auf Ryzen 5000 und 500er Chipsets beschraenkt :rolleyes:

[N0Thing]

Vulkan Ray Tracing Final Specification Release (https://www.khronos.org/blog/vulkan-ray-tracing-final-specification-release)

Es gibt passend dazu auch Beta-Treiber von Nvidia und AMD:

https://developer.nvidia.com/vulkan-driver
https://www.amd.com/en/support/kb/release-notes/rn-rad-win-20-11-2-vrt-beta

[pixeljetstream]

schwere Geburt :) endlich durch

[Dampf]

Unterstützt das auch Inline Raytracing?

[pixeljetstream]

Ja
KHR_ray_query

[Chris Lux]

Ja
KHR_ray_query
Gibt es da auch Pläne, diese inline Ray Queries auch in OptiX/CUDA zu unterstützen? ;)

[pixeljetstream]

Ist nicht meine Baustelle, ich mein der Ansatz da ist immer high level und es wird mindestens das intersection shading gemacht oder so.

[Gast]

Gibt's schon lange: https://raytracing-docs.nvidia.com/optix/api/html/group___prime___query.html

[pixeljetstream]

Gibt's schon lange: https://raytracing-docs.nvidia.com/optix/api/html/group___prime___query.html

Das ist nicht das gleiche, das besondere an ray query ist, dass man es aus jedem normalen shader direkt aufrufen kann, ohne extra pass wie es bei Prime der Fall ist. Die Prime APIs sind auch veraltet, optix 7 ist hier der neue Weg.

[bnoob]

Jetzt können wir auch CUDA auf Vulkan laufen lassen :D

https://github.com/seanbaxter/vulkan_compute

[Dampf]

Jetzt können wir auch CUDA auf Vulkan laufen lassen :D

https://github.com/seanbaxter/vulkan_compute

Sabber... Machine Learning sollte eine ganz wichtige Rolle spielen in der nächsten Generation der Spiele...!

[Gast]

Der verlinkte Code ist ein simples Experiment ueberhaupt CS auf Vulkan laufen zu lassen, kein Circle-Backend.

[Ganon]

Vulkan bekommt wohl eine Video de/encode Erweiterung: https://www.khronos.org/blog/an-introduction-to-vulkan-video

In der ersten Version werden aber nur H.264 und H.265 unterstützt. VP9 und AV1 sollen dann später folgen. Jeder Codec ist dabei eine separate Extension. Wenn das Ganze plattformunabhängig Anklang finden sollte (ja, ich schaue auf dich, Nvidia), könnte es diversen Cross-Plattform Programmen sicherlich gut helfen.

Mal schauen ob es was wird.

[dildo4u]

Blender will OpenCL mit Vulkan ersetzen.


https://www.golem.de/news/3d-grafiksuite-blender-bekommt-support-fuer-pixar-format-und-vulkan-api-2104-155943.html

[THUNDERDOMER]

Jedes Spiel die Vulkan lief, friert oder stürzt immer nach 30 min ab. Doom Eternal schon wieder passiert. Oder Serious Sam 4 (muss dx11 spielen), Quake 2 RTX.

Wie kann ich den Fehler beheben? Bei dx11 (oder älter) oder dx12, OpenGL habe ich das Problem nie.

Treiber schon aktualisiert, neueste. 461.09 auf 471.11

Temperatur sind normales Norm, unter 60 Grad. Kann es nie liegen.

[N0Thing]

Deine Grafikkarte erfüllt nicht die Mindestanforderungen von Doom Eternal. Gleiches bei Serious Sam 4. Evtl. sind die 2GB VRAM zu wenig und die anderen APIs können das durch Auslagern besser kompensieren.

[THUNDERDOMER]

Deine Grafikkarte erfüllt nicht die Mindestanforderungen von Doom Eternal. Gleiches bei Serious Sam 4. Evtl. sind die 2GB VRAM zu wenig und die anderen APIs können das durch Auslagern besser kompensieren.

WHAT? Ich habe rtx 3070...

alles auf hölle, 144 fps stabil. nur 30 min stürzt ab (laut gpu z nur 7400 mb belegt, nie über)

Cyberpunk 2077, alles auf Ultra. 70 fps und keine einzige Abstürze!!! Serious Sam 4 D3D11 kein einzige abszürze, alles auf Ultra, VRAM nie über 6400 MB...) Hired Gun, D3D12 zb läuft auch 144 fps stabil auf max details, nie abstürze.

Es betrifft nur Vulkan. Achja hab auch kein Grafikfehler bei Vulkan, Fehlermeldung nichts, ausser Quake 2 RTX. Nur freeze und schließt das Spiel einfach.

[N0Thing]

Dann solltest du deine aktuelle Hardware auch in deinem Beitrag erwähnen, wenn dein Hardwareprofil noch von anno Tobac ist. :D

[THUNDERDOMER]

Dann solltest du deine aktuelle Hardware auch in deinem Beitrag erwähnen, wenn dein Hardwareprofil noch von anno Tobac ist. :D

Da muss ich echt doch aktualisieren. Versäumt, sorry :O

Hab jetzt aktualisiert. Hat jemand Lösung warum Vulkan crasht?

[THUNDERDOMER]

Problem gehöst. Lag an Nvidia Soundreiber, da gab es konflikt. Ich weiß nicht wieso.

[-/\-CruNcher-/\-]

Bild ich mir das ein oder gehts jetzt mit Unreal 5 so langsam in Richtung stabile Vulkan Performance ?

[dildo4u]

SV9_chUpDgc

[AwesomeSauce]

https://www.khronos.org/blog/reducing-draw-time-hitching-with-vk-ext-graphics-pipeline-library
Khronos has introduced a new extension named VK_EXT_graphics_pipeline_library that allows for shaders to be compiled much earlier than at full Pipeline State Object (PSO) creation time. By leveraging this extension, I was able to avoid many causes of frame hitches due to PSOs being late-created at draw time in the Source 2 Vulkan renderer.
Schön, dass das Problem (CPU-Spikes bei PSO compilation) endlich angegangen wird. Der Blog-Post zeigt auch auf, was genau das Problem ist.

Wäre noch interessant zu wissen, ob DX12 bereits über ähnliche Mechanismen verfügt oder ob das auch noch geplant ist.

While Direct3D11 drivers provide the illusion of compiling entirely with just the shader byte code, the truth is that there are massive heroics happening inside the drivers to make this so. Drivers are often doing background compilation on multiple threads and in fact Direct3D11 cannot guarantee that shader compilation doesn’t happen at draw time. In practice though, GPU vendors have gotten exceptionally good at these heroics, and the typical user experience on a Direct3D11 driver leads to significantly less hitching than our Vulkan renderer without fully prewarmed pipeline caches.
Sowas darf es einfach nicht mehr geben.

[Gast]

Sowas darf es einfach nicht mehr geben.

Das passiert eben, wenn man ein extrem komplexes Problem jeden für sich lösen lässt, anstatt dass es die Spezialisten ein für allemal lösen.

[aufkrawall]

Tja, nur lief schon das erste Vulkan-Spiel (Doom 2016) komplett ohne Shader Compile Stutter.

[AwesomeSauce]

Tja, nur lief schon das erste Vulkan-Spiel (Doom 2016) komplett ohne Shader Compile Stutter.
Darauf wird auch eingegangen:

A second caveat is that if you are designing a new engine for Vulkan, you should really consider whether having large numbers of shader permutations is a good idea. Some games, such as DOOM 2016/DOOM Eternal have kept to having a very small number of PSOs. Describing this design space in detail is beyond the scope of this blog post, but I highly recommend reading this two part blog series that explains why many engines have large numbers of shader permutations (which is one of the root causes of many draw time compile hitches): The Shader Permutation Problem: How Did We Get Here? (https://therealmjp.github.io/posts/shader-permutations-part1/)
Ist nun mal nicht in jedem Spiel möglich.

[Gast]

Tja, nur lief schon das erste Vulkan-Spiel (Doom 2016) komplett ohne Shader Compile Stutter.
Was daran liegt dass Doom nur ne handvoll shader hat.

Das Problem was valve hier beschreibt zielt eher auf ihre engine und zum Teil auch ältere Titel bzw. DX nach VK layer ab.

Viele engines leiden noch mehr daran dass es grundsätzlich viel shader Code gibt und da hilft diese Lösung immer noch nicht. Dafür braucht es sowas wie linking von Funktionen innerhalb des shaders... was nachwievor keine Grafik api hat. Aber alle wissen um das Problem. Will nur sagen dass selbst mit dieser extension das Problem nicht komplett gelöst ist.

[aufkrawall]

Na ja, z.B. Control hat auch nur wenige verschiedene Shader bzw. Mutationen, und trotzdem kompiliert es sie nicht sauber vorab.
Wenn neue Extensions manche Entwickler hoffentlich vor Irrtümern bewahren, ist das natürlich gut. Aber ging, mit etwas Grips, wie gesagt schon längst. Nur macht etwa die UE dahingehend Entwicklern offenbar das Leben ziemlich schwer und es scheint größeren Projekten mit eigener Engine leichter zu fallen.

Gibt seit kurzem auch VK_EXT_pipeline_robustness und wird API-Wrappern weiter helfen (vorerst nur in RADV und Nvidia Vulkan-Dev-Treiber). Etwa gibts in vielen D3D11-Spiele damit mit DXVK schon gar kein Shader Compile-Stocken mehr bzw. nicht mehr als nativ.

[Troyan]

nVidia's RTX Remix nimmt sich DX8/DX9 Code und portiert das automatisch nach Vulkan und dann lässt sich Raytracing und DLSS integrieren: https://www.nvidia.com/en-us/geforce/news/rtx-remix-announcement/?ncid=em-news-607920#cid=dt005_em-news_en-us

[basix]

Cooles Feature. Nachfolger für Gothic 1/2 DX11 Renderer? :D

[aufkrawall]

Wohl nicht, weil DirectDraw. Hoffentlich irgendwann Native Path Tracing-Implementierung in Open Gothic.

[DrFreaK666]

Wohl nicht, weil DirectDraw. Hoffentlich irgendwann Native Path Tracing-Implementierung in Open Gothic.

Gothic nutzte schon 3D-Karten. Wahrscheinlich DX7

[aufkrawall]

Das Spiel ruft nur die ddraw.dll auf, nichts von D3D.

[DrFreaK666]

ok. Den DX11 Renderer gibt es ja nur für G2