Vulkan Grafik-API [Archiv] - Seite 8

-/\-CruNcher-/\-

2016-08-11, 14:28:57

Nvidia hat erst mit Tegra so richtig ausgebaut und teilt Intel war schon lange davor am teilen
das teilen bei Nvidia bezieht sich aber wie gesagt zum großteil nur auf Tegra dort wollen sie Platform erfolge sehen.
Indirekt bezieht es sich auch auf den Desktop ist ja die selbe einheitliche Ökosystem Strategie die auch AMD fährt mit Microsoft wo Nvidia momentan eher nur 2nd ist.

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

Das siehst du falsch Vulkan brauch man nicht auf Mobile um Performance zu generieren sondern um weiter Kosten zu sparen die Performance ist ein Vorteil der sich so ergibt die Kosten werden hauptsächlich ausgelagert ;)

Lean Management @ it's best die Entwickler und Publisher machen ja mit sollen sie ein teil der Kosten tragen und sich nicht nur auf die Treiber Entwicklung ausruhen ;)

In dem Kontext macht es für Intel auch keinen sinn Vulkan auf Windows zu pflegen wenn schon DX 12 als Platform API feststeht wird es eh jeder große Entwickler supporten müssen, das wären nur zusätzliche unnötige Kosten die man ohne richtigen Demand schlussrichtig nicht investieren wird das ist im moment eine gute vernünftige Entscheidung im Sinne der Intel Aktionäre die Vulkan Resourcen erstmal auf non Windows zu konzentrieren ;)
Zumal Intel selbst nicht will das zu viele bei Pre Windows 10 hängen bleiben und schnell wechseln ;)

Foobar2001

2016-08-11, 17:17:44

Alter laberst du eine Scheiße. Niemand "muss" in AAA Intel supporten. Die können froh sein, wenn das Spiel ohne Fehler läuft. Nicht mal getestet wird darauf in der Regel. Schau dir doch die Mindestanforderungen auf den Packungen an.

DanMan

2016-08-11, 17:56:33

Zumal Intel selbst nicht will das zu viele bei Pre Windows 10 hängen bleiben und schnell wechseln ;)
Das wär was für's Kartellamt.

kruemelmonster

2016-08-13, 16:18:35

Nvidia hat erst mit Tegra so richtig ausgebaut und teilt Intel war schon lange davor am teilen
das teilen bei Nvidia bezieht sich aber wie gesagt zum großteil nur auf Tegra dort wollen sie Platform erfolge sehen.

Du hast wiedermal keine Ahnung wovon du sprichst, iuno im Gegensatz schon, also warum mußt du hier inhaltslos rumfaseln?
Es geht nicht um die Tegras, sondern darum dass die Linuxe, FreeBSDs und Solaris Maschinen sich bei NV einen Treiberkern mit Windows teilen.

Kartenlehrling

2016-08-15, 11:27:19

Parallel zur Gamescom gibts wohl auch eine GDC Europa 2016.

http://schedule.gdceurope.com/session/vulkan-games-benefit-from-khronos-explicit-graphics-compute-api-presented-by-khronos-group
Monday, August 15 | 10:00 - 11:00
Vulkan: Games Benefit from Khronos' Explicit Graphics & Compute API (Presented by Khronos Group)

Monday, August 15 | 13:15 - 14:15
Vulkan Roundtable: The First Six Months- What Have We Learned? (Presented by Khronos Group)

Tuesday, August 16 | 11:15 - 12:15
D3D12 & Vulkan: Lessons Learned

deekey777

2016-08-16, 08:58:09

Locuza

2016-08-16, 13:13:54

Laut einem Gaf-Nutzer ist das V-Sync Verhalten mit dem neusten Nvidia-Treiber unter Doom gefixt:
The new NV driver (372.54) fixed the stuttering with vsync on. They've also bumped the supported Vulkan version to 1.0.13.

http://www.neogaf.com/forum/showpost.php?p=213798534&postcount=520

Unicous

2016-08-16, 16:28:07

http://m.heise.de/newsticker/meldung/Vulkan-Erste-Bilanz-Kritik-an-Metal-und-eine-Einladung-an-Apple-3295221.html

Man ist grundsätzlich zufrieden.

Scharfe Worte gegen Nvidia

Tobias Hector, Software Design Engineer bei Imagination Technologies, schoss kurz vor Ende der Veranstaltung noch gegen Nvidia: Jeder profitiere stark von Vulkan, nur Nvidia nicht. Hector spielt damit offenbar auf Nvidias ineffiziente Implementierung der Technik Asynchronous Compute an. Der Nvidia-Vertreter hatte dem nichts als ein verlegenes Lächeln entgegenzusetzen.

Was ist denn da los?:eek:

iuno

2016-08-16, 17:50:19

Was ist denn da los?:eek:

Tobias Hector, Software Design Engineer bei Imagination Technologies, schoss kurz vor Ende der Veranstaltung noch gegen Nvidia: Jeder profitiere stark von Vulkan, nur Nvidia nicht. Hector spielt damit offenbar auf Nvidias ineffiziente Implementierung der Technik Asynchronous Compute (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html) an.
Offenbar hat mfi den letzten Satz nur eingebaut, um auf einen weiteren Artikel verlinken zu koennen und Tobias Hector hat nichts diesbezueglich gesagt. Dass er auf fehlendes AC bei NV anspielt, ist die Interpretation von mfi und darauf gebe ich gar nichts :rolleyes: Zumal das in meinen Augen auch keinen Sinn ergibt, da ImgTec da sicher auch nicht annaehernd auf AMD Niveau liegt. Es ging wohl eher um Vulkan an sich und was NV macht oder nicht macht, um am Ende gut dazustehen. Bevor es da keine weitere Meldung oder bestenfalls ein Video gibt, wuerde ich aber keine Wertung wagen. Leider ist das Interesse bei der GDCE nicht besonders gross

Kartenlehrling

2016-08-16, 17:59:57

Nvidia wird das Ausmerkeln bis ihre NVapi es kann oder die Hardware stimmt.

Added a Windows cross-API interop between Vulkan and DirectX 11.
This enables Vulkan app compatibility with existing DirectX 11-based HMD runtimes.

Was bedeute das denn jetzt genau?

HOT

2016-08-16, 18:10:17

Offenbar hat mfi den letzten Satz nur eingebaut, um auf einen weiteren Artikel verlinken zu koennen und Tobias Hector hat nichts diesbezueglich gesagt. Dass er auf fehlendes AC bei NV anspielt, ist die Interpretation von mfi und darauf gebe ich gar nichts :rolleyes: Zumal das in meinen Augen auch keinen Sinn ergibt, da ImgTec da sicher auch nicht annaehernd auf AMD Niveau liegt. Es ging wohl eher um Vulkan an sich und was NV macht oder nicht macht, um am Ende gut dazustehen. Bevor es da keine weitere Meldung oder bestenfalls ein Video gibt, wuerde ich aber keine Wertung wagen. Leider ist das Interesse bei der GDCE nicht besonders gross
Hm auf was soll das denn sonst anspielen? NVs zögerlichen Treibersupport?

Unicous

2016-08-16, 18:25:20

@iuno

Das stimmt so nicht und verstehe auch nicht wie du das behaupten kannst.:confused:

Aaaaaber... offensichtlich war es wirklich nur Teasing seitens Hector

haha. For theatrical purposes Markus and I [had] a spat on stage. We're best of frenemies really 😜

yea their article is weird. Markus said that you won't really expect a GPU perf improvement. I dramatically rebutted it ¯\_(ツ)_/¯
https://twitter.com/TobskiHectov/status/765453441586126848

Dass heise/ct' dramatisch an Qualität eingebüßt haben würde ich aber denoch bestätigen.:wink:

SaschaW

2016-08-16, 18:50:05

Zitat:
Added a Windows cross-API interop between Vulkan and DirectX 11.
This enables Vulkan app compatibility with existing DirectX 11-based HMD runtimes.
Was bedeute das denn jetzt genau?

Vermutlich das Selbe wie die OpenGL Interoperability. D.h. man kann zwischen den APIs syncen und ein Vulkan Image in einen GL/DX11 Framebuffer rendern.

Für HMDs die nur eine DX11-Unterstützung anbieten kann man so trotzdem jetzt schon Vulkan nutzen und präsentiert das fertig gerenderte Bild dann letztendlich nur noch mit DX11/GL. Optional kann man dann die beiden nutzen um UI-Overlays über die Szene zu legen.

iuno

2016-08-16, 19:08:08

Das stimmt so nicht und verstehe auch nicht wie du das behaupten kannst.:confused:
Und ich verstehe nicht, was du mir unterstellst. Was soll ich behauptet haben, was nicht stimmt?
Markus said that you won't really expect a GPU perf improvement. I dramatically rebutted it ¯\_(ツ)_/¯
Das ist jedenfalls schonmal was voellig anderes, als das, was mfi geschrieben hat.
Hm auf was soll das denn sonst anspielen? NVs zögerlichen Treibersupport?
Wie gesagt, ohne weiteres Material wuerde ich da einfach gar nicht versuchen irgendetwas hineinzuinterpretieren, das hat sich jetzt aber sowieso erledigt

Unicous

2016-08-16, 19:24:47

iuno

2016-08-16, 19:31:06

Unsinn, lies genauer.

-/\-CruNcher-/\-

2016-08-17, 00:30:54

Du hast behauptest, es habe keinen Disput gegeben und das kannst du nicht einmal belegen.:rolleyes: Wie das Streitgespräch von Martin Fischer (der offensichtlich vor Ort war) interpretiert wird, steht natürlich auf einem anderen Blatt.

Und ich weiß nicht wie du hier offenbar definierst, es ist ganz klar eine Vermutung.

Das ist doch ganz normal auch Imgtec und Qualcom sind sich bei einigem uneinig die Zeit wird es zeigen wer Recht behält ;)

Das es da Spannungen in so eine Standard Group gibt ist ganz normal das man manchmal sachen raus läst die man besser nicht sagt vor allem als Engineer auch und das man die danach dementiert ist genauso normal, wobei hier kann man nicht mehr dementieren hier muss man es dann runterspielen als scherz ect ;)

Man bekommt eigentlich in jeder Schulung mit das man vorsichtig mit Anspielungen gegenüber den anderen am Tisch sein sollte, das kann man Intern behandeln aber extern hin zur öffentlichkeit sollte man das lassen sich die Messer gleich in den rücken zu jagen vor allem als Engineer sollte man seine Meinung zu den anderen doch Leger unter Kontrolle halten vor allem da man mit seiner Überzeugung ja durchaus in Zukunft auf die schnauze fliegen könnte, sich die Messer gegenseitig in den Rücken ramen können die anderen später besser ;)

Einige scheinen einfach nicht zu verstehen das wenn ich da rauf gehe eben einen Talk über meine Hardware Grundlage als IHV vertretter abliefere und diese auch immer in den Vordergrund stelle wenn nun der Nvidianer sagt das man keine GPU Performance erwarten sollte dann spricht er darüber in seinem jetzigen breiten markt abdeckenden Hardware kontext nichts anderes.

Die ersten daten Zeigen eben auch das man momentan froh sein sollte wenn zumindestens die Stabile Performance gewährleistet werden kann unter einander als wie einen extremen Performance boost durchweg beim thema Async Compute zu erwarten und das steht auch sehr eng im kompletten System Kontext ;)

Dennoch objektiv war das von MFI nicht wirklich das ganze so selbst interpretiert auch zu veröffentlichen man muss dem Leser schon die Meinungsbildung überlassen ;)

Kartenlehrling

2016-08-17, 19:01:03

Vulkan Tutorial (https://vulkan-tutorial.com/Introduction)

SaschaW

2016-08-17, 20:01:59

Wer mit Vulkan entwickelt: NVIDIAs Nsight kann jetzt auch mit Vulkan (https://developer.nvidia.com/nvidia-nsight-visual-studio-edition). Von AMD und ARM gibts ja bereits vergleichbares, und RenderDoc nutzt man als Vulkanentwickler ja eh schon, wobei dass leider noch nichts in Richtugn Profiling kann.

Hübie

2016-08-17, 21:37:29

Also seit Doom wünsche ich mir deutlich mehr Vulkan-Support seitens der Spieleentwickler. Ich befürchte jedoch, dass man da größtenteils gegen Windmühlen ankämpft.

Achill

2016-08-17, 23:00:34

Also seit Doom wünsche ich mir deutlich mehr Vulkan-Support seitens der Spieleentwickler. Ich befürchte jedoch, dass man da größtenteils gegen Windmühlen ankämpft.

Vulkan sehe ich groß kommen für die Linux- und Android-Welt. Neben den ganzen tollen neuen API-Aspekten hat Vulkan einen weitern (wenn nicht den bedeutenden) Vorteil: Doku/Spec sowie Compliance-Tests sind offen, verfügbar, werden kontinuierlich Ausgebaut und sollen in einen besseren/eindeutigeren Weise verfasst sein

(Irgendwo bei einen Talk eine Bemerkung dazu gehört - hoffe das stimmt auch so).

Hübie

2016-08-17, 23:13:02

Das ist leider nicht genug, da >95% eben Windows zum Zocken nutzen und die meisten Spiele (95%+??), welche 2016+ erscheinen haben kein Linux-Support. Android interessiert mich mal so überhaupt nicht, da kann es verbreitet sein wie Flip, es würde niemand wirklich wissen (Massenphänomen halt). ^^
Das ist traurig aber eben bittere Wirklichkeit.

iuno

2016-08-17, 23:25:35

Weil es so ein grosser Markt ist, haben die grossen Engines aber inzwischen idR. Android Support, kleinere Studios gehen wohl auch den Vulkan Weg, wenn man technisch einigermassen was abliefern und konkurrieren will. Das wird imho schon Einfluss haben, dass sich insgesamt so viele Entwickler mit Vk beschaeftigen. Wenn Nintendo jetzt noch Vulkan unterstuetzt, kommt nochmal was dazu. Dabei ist voellig egal, ob man sich fuer den Mobilkram interessiert oder nicht.
Zudem hat von deinen 95% Windows vielleicht die Haelfte Windows 10, kann also durch gleichwertige Konkurrenz bedient werden. Ich sehe Vulkan immer noch als einzig logischen Gewinner in diesem Duell. Natuerlich waere es aber wichtig, dass bald mal mehr hochqualitative Titel nachkommen. Zumal es bisher quasi jeder d3d12 Titel versaut hat, Vk hat da noch nicht dieses Image.

Loeschzwerg

2016-08-18, 07:12:19

Abwarten. Wenn schon ein Vorzeigeprojekt wie Doom immer noch nicht offiziell für Linux verfügbar ist... :(

HOT

2016-08-18, 08:00:48

Vulkan ist noch neuer als DX12. Da DX12 aber nur für Win10 funktioniert und ca. die Hälfte der Zielgruppe sich weigert auf Win10 zu wechseln, man aber irgendwann auf neue APIs setzen muss, weil DX11 wirklich am Ende ist bleibt eigentlich nur Vulkan mittelfristig, da wird sich jedes Studio mit beschäftigen. Da könnte sich M$ mit seiner Politik massiv ins eigene Knie geschossen haben.

Loeschzwerg

2016-08-18, 08:55:53

Pfff... bis jetzt ist noch so gut wie jeder "Weigerer" umgestiegen. Da gibt es ein paar Schwätzer inkl. Mitläufern in den üblichen Foren und der große Knall bleibt trotzdem aus. Gleiches Spiel wie bei AMD vs NV.

Iruwen

2016-08-18, 12:01:28

Die Verweigerer zocken auf den Kisten einfach nicht.

Screemer

2016-08-18, 12:14:42

Dann schau mal hier ins Forum. Da gibt's genug die nicht auf win10 umsteigen wollen.

Iruwen

2016-08-18, 12:33:37

Das Forum ist in keinem Bereich repräsentativ.

=Floi=

2016-08-18, 13:09:07

gibt es den quake 1 vulkan port auch compiliert?
hat der auch irgendwelche vorteile? ich denke der overhead wird dort noch nicht so gigantisch sein...

Kartenlehrling

2016-08-18, 13:23:25

Mit dem Microsoft "Geschenk" des kostenfreiem Update ist es auch nicht schwer, ich hab eine Win7home-OEM auf Win10home,
eine PC-Fritz Win7pro auf Win10pro und eine Win8update die läuft erstmal weiter auf Win8.1.

Heute wo es eine 240gb SDD für 60€ gibt, war es auch kein Problem sich ein sauberes Betriebsytem zu installieren,
so habe ich 2 Rechner mit 4 Betriebsytem ( MacOX/Win10home und Win8.1pro mit Win10pro) und
durch Wechselrahmen in 2min ausgetauscht wenn ich umbedingt eins der 3-5 DX12 Spiele starten will.

In 2 oder 5 Jahren kann man immer noch nur die Win10pro im Rechner stecken lassen.
Die Eintagsfliege Doom hat gezeigt das es auch ohne DX12 und Win10-anniversary update geht.

Profitiert eigentlich Vulkan auch von Anniversary Update oder ist das nur für DX12?

dargo

2016-08-18, 13:31:38

Nur Direct3D.

iuno

2016-08-18, 14:17:17

Abwarten. Wenn schon ein Vorzeigeprojekt wie Doom immer noch nicht offiziell für Linux verfügbar ist... :(

Das hat ja nicht mal technische Gründe. Die beta lief offenbar (nicht selbst probiert) ziemlich perfekt mit wine, aber der Publisher hat offenbar keinen Bock. Mit Vulkan an sich hat das aber wenig zu tun

Loeschzwerg

2016-08-18, 16:39:27

Ja, das liegt am Denuvo.

Ich meine nur, wenn jetzt dann wieder nur größtenteils Win bedient wird (trotz VLK Nutzung), dann ist damit irgendwie auch nichts gewonnen.

iuno

2016-08-18, 18:39:17

Genau. DRM laesst sich natuerlich auch auf Linux realisieren, oder man laesst es einfach, weil es eh nichts bringt. Wie gesagt, nicht technisch sondern "politisch". Den Leuten, die sowas entscheiden, kann man mit Vulkan auch nicht helfen. Das eine hat mit dem anderen halt nichts zu tun.

Man gewinnt trotzdem was; Windows 7 und 8/8.1 Kunden koennen genauso bedient werden und man bindet sich einfach nicht an MS. So eine Bindung bringt immer Risiken. Und sollte eine kritische Masse an Kunden irgendwann anfangen, sich nicht mehr ausnahmslos alles gefallen zu lassen, kann man schnell ausweichen. Natuerlich waere es schoen, wenn auch mal vorher was passieren wuerde und nicht immer erst hinterher...

fondness

2016-08-18, 18:49:31

Vielleicht mal an die ganzen Leute, welche meinen Doom@Vulkan ist Beta um die schwache Nvidia-Leistung zu rechtfertigen:

https://s4.postimg.org/mwv15vwct/Clipboard01.jpg (https://postimg.org/image/kfj9ymcg9/)

Birdman

2016-08-18, 20:15:12

na ja, wenn Coda ein "Drivers are perfeclty fine" von sich gibt, dann muss ich schon die Stirn runzeln.
Wenn er Vulkan@Doom anstelle einer Fury auch mal auf einer nVidia Karte getestet hätte, wäre ihm sicher aufgefallen dass deren Treiber viele lustige framedrops erzeugt und das Spiel ganz allgemein deutlich unrunder als unter OpenGL läuft.
Wenn die nV Treiber ja so "perfekt" sind, wieso spielen dann alle Geforce User das Spiel unter openGL?
Wenn Vulkan@Doom keine beta mehr sein soll, kann es ja nur an grottigen Treibern liegen.

Screemer

2016-08-18, 20:26:12

Immer ist der Typ ehrlich und gibt zu, dass der Vulkan-Pfad auf nVidia-Hardware nicht "correct used" wurde.

Wahrheit ist der erste Schritt zur Besserung.
Deswegen ist das auch nur durch nen neuen nv Treiber bereinigt worden. Stfu wäre eigentlich die richtige und kürzste Antwort. Der Post ist von heute und somit sind die stand heute "just fine".

Schnoesel

2016-08-18, 20:45:09

Wenn die nV Treiber ja so "perfekt" sind, wieso spielen dann alle Geforce User das Spiel unter openGL?

Wenn du alles lesen würdest steht da noch ein kleiner gemeiner Satz "if used correctly". Also wenn Nvidia das in ihrem Treiber nicht hinbekommt ... soll das Coda für sie machen oder sind sie noch bei der AC Implementierung für Maxwell?

Lurtz

2016-08-18, 20:53:24

Wenn du alles lesen würdest steht da noch ein kleiner gemeiner Satz "if used correctly". Also wenn Nvidia das in ihrem Treiber nicht hinbekommt ... soll das Coda für sie machen oder sind sie noch bei der AC Implementierung für Maxwell?
Bei AMD liegen Probleme am Treiber, bei nVidia liegts am Entwickler, ist doch bekannt :deal:

Darkman.X

2016-08-19, 00:17:40

OpenGL ist stets flotter, mehr Argumente braucht es nicht.

Ich finde es ja toll, wie du dich um diese Treibergeschichten usw. kümmerst, aber das ist doch jetzt etwas heftig für mich, selbst als langjähriger nVidia-Nutzer.

Bloß weil bei nVidia OpenGL schneller läuft als Vulkan, soll die Schuld bei Doom und dessen Vulkan-Implementierung und nicht bei nVidia liegen? Ich würde ja jetzt fragen ob du den Blödsinn wirklich selber glaubst, aber das traurige ist, dass du vermutlich mit "ja" antworten würdest...

EDIT: Falls du die anderen Threads nicht so mitverfolgst...zumindest laut "Coda" ist da nichts experimentell: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=11135114#post11135114

Blaire

2016-08-19, 00:26:09

Ich finde es ja toll, wie du dich um diese Treibergeschichten usw. kümmerst, aber das ist doch jetzt etwas heftig für mich, selbst als langjähriger nVidia-Nutzer.

Bloß weil bei nVidia OpenGL schneller läuft als Vulkan, soll die Schuld bei Doom und dessen Vulkan-Implementierung und nicht bei nVidia liegen? Ich würde ja jetzt fragen ob du den Blödsinn wirklich selber glaubst, aber das traurige ist, dass du vermutlich mit "ja" antworten würdest...

Keine Ahnung worauf du abzielst, aber so interessant ist Vulkan nun auch wieder nicht. Warum sollte ich auf den Hypezug aufspringen ohne das es irgendeinen Nutzen bringt? Nenn mir doch bitte ein schlüssiges Argument? :)
Ob die Schuld beim Entwickler liegt oder NVIDIA das kann ich nicht beurteilen und muss mich auch nicht interessieren.

: Falls du die anderen Threads nicht so mitverfolgst...zumindest laut "Coda" ist da nichts experimentell: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=11135114#post11135114

Was sollte er sonst äußern? Stell dir nur mal vor , es wäre andersrum gelaufen wie die Schreihälse wieder am jammern wären. Mir persönlich ist das alles ziemlich egal, ganz ehrlich. Ich entscheide zum Glück immer noch SELBST, was gut ist und was nicht. DOOM@OpenGL rennt ausgezeichnet.

Darkman.X

2016-08-19, 00:38:35

Foobar2001

2016-08-19, 01:25:25

Blaire

2016-08-19, 02:29:32

User beklagen Probleme und von dir kommt halt nur soetwas wie "experimentell", weil ja OpenGL als Beweis schneller läuft. Das ist eine Aussage, die könnte auch direkt von einem nVidia-Angestellten kommen. Und man weiß ja auch nicht, welche Infos du so hast. Lässt du da etwas inoffizielles von nVidia durchblicken oder ist das ausschließlich deine persönliche Meinung?

Ob jetzt objektiv betrachtet Vulkan bei Doom Sinn macht / notwendig ist oder nicht, das ist eine andere Geschichte. Für mich als stiller Mitleser steht erstmal die Tatsache im Raum, dass Vulkan bei nVidia wohl immer noch nicht ganz sauber läuft. Für jemanden, der ein x-mal größere Budget als AMD hat, ist das schon etwas traurig...

Das ist meine persönliche Meinung und selbst wenn ich Details kenne, würde ich die hier nicht äußern, das stünde mir auch garnicht zu. Fakt ist, das Game kam mit OpenGL auf den Markt, Vulkan wurde erst später per Patch nachgeliefert. Warum also sollte Vulkan urplötzlich eine höhere Priorität genießen? Glaubst du das wirklich? :) Zudem legten die GeForce-Treiber unter OpenGL stets an Leistung zu, so auch mit diesen Treiber, sprich die Optimierungen sind noch nicht abgeschlossen. Für Vulkan gabs Bugfixes und V-Sync Stutter wurde beseitigt, ebenso G-Sync (Fullscreen) ermöglicht. Vieleicht sind deine Erwartungen da einfach nur überzogen? Aber sicher ist das alles noch experimentell zu werten, wie würdest du es sonst nennen, wenn nichtmal die Grundfunktionen korrekt funktionierten?
Der Entwickler hat(te) es da ja offensichtlich auch nicht so eilig (oder halt doch , je nach Standpunkt) wie du auch im offiziellen FAQ nachlesen kann.
https://steamcommunity.com/app/379720/discussions/0/358417461601870117
"We are working with NVIDIA to enable asynchronous compute in Vulkan on NVIDIA GPUs. We hope to have an update soon."
Ein schlüssiges Argument warum man denn nun dringend Vulkan braucht, kannst du ja offensichtlich auch nicht nennen. Macht das Game unter OpenGL weniger Spaß, was verpasst man? ...

The_Invisible

2016-08-19, 06:56:48

Vulkan/DX12 wird bei nvidia derzeit einfach nicht so eine große Priorität haben. AMD ist hier anscheinend schon weiter weil sie damit einfach besser ihre GPUs auslasten können.

Außerdem sind fps nicht alles siehe auch http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11135155&postcount=4674

SaschaW

2016-08-19, 08:08:27

gibt es den quake 1 vulkan port auch compiliert?
hat der auch irgendwelche vorteile? ich denke der overhead wird dort noch nicht so gigantisch sein...

Ja, direkt im Repo unter Releases (https://github.com/Novum/vkQuake/releases).

dargo

2016-08-19, 08:23:21

Keine Ahnung worauf du abzielst, aber so interessant ist Vulkan nun auch wieder nicht. Warum sollte ich auf den Hypezug aufspringen ohne das es irgendeinen Nutzen bringt? Nenn mir doch bitte ein schlüssiges Argument? :)

Du meinst keinen Nutzen so wie hier?
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11099537&postcount=1272

Birdman

2016-08-19, 12:41:08

Du meinst keinen Nutzen so wie hier?
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11099537&postcount=1272
Das mit dem Nutzen ist halt sehr indivduell ;)
Der nVidia Krösus mit den auf 4.xGhz hochgeprügelten Intel 6-Kernern sieht halt wirklich keinen Vorteil.
Beim ganzen Pöbel mit alten Rechenknechten bringt Vulkan aber durchaus ein deutliches mehr an FPS.

Bei Radeon Usern sieht das etwas anders aus, da diese aufgrund spezifischer AMD Optimierungen (Intrinsics, Frame-Flip, AC) in Vulkan@Doom, selbst im GPU Limit zulegen können und daher immer profitieren, auch bei der Verwendung von Enthusiast CPUs.

iuno

2016-08-19, 13:35:34

Das ist meine persönliche Meinung und selbst wenn ich Details kenne, würde ich die hier nicht äußern, das stünde mir auch garnicht zu. Fakt ist, das Game kam mit OpenGL auf den Markt, Vulkan wurde erst später per Patch nachgeliefert. Warum also sollte Vulkan urplötzlich eine höhere Priorität genießen? Glaubst du das wirklich? :)
Vulkan war bei id schon lange ein Thema und die Unterstuetzung fuer DOOM war zum Release schon fast fertig. Dass man noch etwas Feinschliff vorgenommen hat, spricht fuer die devs, das Releaseziel hat man ja trotzdem erreicht. Ich verstehe nicht wie man daraus schon wieder Negatives schlussfolgern kann

aufkrawall

2016-08-19, 13:53:09

Fakt ist nun mal auch, dass es auf NV schon ab Day 1 mit OpenGL gut lief und das mit weiteren Treibern noch weiter verbessert wurde.
Kann mir schon vorstellen, dass NV die Prioritäten da anders gesetzt hat und die Ressourcen stärker in die OpenGL-Optimierungen als in den Vulkan-Treiber gingen. Was ja nicht gegen das Kundeninteresse ist.
Nur sollte angesichts der starken AMD-Ergebnisse jetzt halt doch noch was kommen. id haben ja noch was angekündigt. Wird jetzt spannend, was daraus wird, und ob man NV dann womöglich zurecht den schwarzen Peter zuschiebt, wenn es eben nicht klappen sollte.

Schnoesel

2016-08-19, 14:15:59

iuno

2016-08-19, 14:20:19

Laut cryengine Roadmap soll Vulkan ab 5.3 (Oktober) am Start sein
https://www.cryengine.com/roadmap

\o/

aufkrawall

2016-08-19, 14:23:23

Auch Nvidia profitiert von Vulkan (oder würde es), fällt nur gerade nicht ins Auge wenn man einen max. OC High End CPU nutzt (wie in den meisten Benches). Ziemlicher Tellerrand es würde Nvidia nicht auch Vorteile bringen. Wegen AMD allein hat man Vulkan und DX12 sicherlich nicht eingeführt.
Klar. Eine Titan X mit einer synthetisch runtergetakteten 1,2Ghz CPU zu versorgen ist ja mal voll weitblickend über den Tellerrand geschielt. :freak:

Schnoesel

2016-08-19, 14:36:41

Wir können uns jetzt an dem ziemlich konstruiertem Beispiel aufhängen oder einfach mal auf die Rechner dieser Welt blicken. Alter Sandy mit GTX 980, I3 mit GTX 970 etc. Auch die können von einem geringeren CPU Overhead profitieren. Hängt natürlich auch vom Spiel ab. Aber pauschal zu sagen, dass es keinen Nutzen bringen würde ist ja wohl Käse. Die besseren Frametimes bei richtiger Implementierung noch gar nicht erwähnt.

aufkrawall

2016-08-19, 14:53:54

Bei richtiger Implementierung sind die Frametimes mit Low Level nicht besser, weil sie auch mit High Level perfekt sein können.
Und trotzdem ist das Spiel unter Nvidia OpenGL mit ausgewogenen Hardware-Konfigurationen kaum bis überhaupt nicht CPU-limitiert.
Worte in den Mund legen ist übrigens keine nette Angewohnheit, von "nichts bringt" hab ich nämlich überhaupt nichts gesagt...

dargo

2016-08-19, 14:55:24

Klar. Eine Titan X mit einer synthetisch runtergetakteten 1,2Ghz CPU zu versorgen ist ja mal voll weitblickend über den Tellerrand geschielt. :freak:
Darum gehts doch gar nicht. Stelle dir mal vor wir hätten heute schon bei jedem Spiel ein natives DX12/Vulkan. Dann wären CPUs für 300+€ praktisch obsolet. Dass viele Enthusiasten eine starke CPU heute im Rechner haben ist nur die Folge der Steinzeit APIs.

Schnoesel

2016-08-19, 14:58:16

von "nichts bringt" hab ich nämlich überhaupt nichts gesagt...

Das war nicht auf dich gemünzt. Blaire hat diese Wortwahl benutzt:

Warum sollte ich auf den Hypezug aufspringen ohne das es irgendeinen Nutzen bringt?
________________________________________________________________________________ ____

Und trotzdem ist das Spiel unter Nvidia OpenGL mit ausgewogenen Hardware-Konfigurationen kaum bis überhaupt nicht CPU-limitiert.

Darum sagte ich ja dass es Spielabhängig ist.

iuno

2016-08-19, 15:11:04

Darum gehts doch gar nicht. Stelle dir mal vor wir hätten heute schon bei jedem Spiel ein natives DX12/Vulkan. Dann wären CPUs für 300+€ praktisch obsolet.
Ich glaube nicht. Wir haetten dann hoffentlich mehr Physik, bessere KI, usw.... ;p

aufkrawall

2016-08-19, 15:20:48

Darum gehts doch gar nicht. Stelle dir mal vor wir hätten heute schon bei jedem Spiel ein natives DX12/Vulkan. Dann wären CPUs für 300+€ praktisch obsolet. Dass viele Enthusiasten eine starke CPU heute im Rechner haben ist nur die Folge der Steinzeit APIs.
Ich sage nicht, dass Low Level keinen Sinn mit NV machen würde. Mir ging es nur darum, dass der Vorteil bei diesem konkreten Titel mit typischer CPU/GPU-Kombination überschaubar ist.

Man sollte auch nicht immer annehmen, als wär High Level AMD vergleichbar zu High Level NV, was die CPU-Performance angeht.
Nur mal so als Anregung: In Just Cause 3 mit der 390 hab ich in 720p (CPU-Limit) während des Glidens über die Anfangs-Stadt 50fps Minimum, mit der 1070 sind es 75.
Das ist auch mal eben ein Vorsprung von 50%.

Und btw. hätte ich für Doom lieber eine bessere Grafik und bessere Multicore-Unterstützung gehabt als Vulkan. Wie man bei dem Bild mit der Titan X sieht, sind trotz krassem CPU-Limit bei 1,2Ghz nur drei Cores ausgelastet.
Assassin's Creed: Syndicate lastete bei meinem Bruder mit NV in 720p acht Threads zu 100% aus bei ca. 100fps.
Irgendwas sagt mir, dass Doom nach Erscheinen von BF1 niemanden mehr interessieren wird.

dargo

2016-08-19, 15:20:58

Ich glaube nicht. Wir haetten dann hoffentlich mehr Physik, bessere KI, usw.... ;p
Hätten wir nicht. Es gibt praktisch nichts mehr exklusives im AAA-Bereich für den PC. Den Ton gibt der kleinste Nenner bei Multiplattform an. Und das wäre die XB1.

dargo

2016-08-19, 15:27:44

Man sollte auch nicht immer annehmen, als wär High Level AMD vergleichbar zu High Level NV, was die CPU-Performance angeht.
Nur mal so als Anregung: In Just Cause 3 mit der 390 hab ich in 720p (CPU-Limit) während des Glidens über die Anfangs-Stadt 50fps Minimum, mit der 1070 sind es 75.
Das ist auch mal eben ein Vorsprung von 50%.

Man sollte sich bei diesem Beispiel aber auch mal die Frage stellen ob es einen FW337.50 ohne Mantle in dieser Form heute überhaupt gäbe? DX11 begleitet uns immerhin schon seit über 7 Jahren. Warum gab es also diese Verbesserungen nicht schon viel früher?

Und btw. hätte ich für Doom lieber eine bessere Grafik und bessere Multicore-Unterstützung gehabt als Vulkan. Wie man bei dem Bild mit der Titan X sieht, sind trotz krassem CPU-Limit bei 1,2Ghz nur drei Cores ausgelastet.

Für was denn? 400fps? :tongue:

iuno

2016-08-19, 15:45:48

Hätten wir nicht. Es gibt praktisch nichts mehr exklusives im AAA-Bereich für den PC. Den Ton gibt der kleinste Nenner bei Multiplattform an. Und das wäre die XB1.
klar gibt es noch pc exclusives.

Robspassion

2016-08-19, 16:00:01

Hi,

ich habe seit dem neuen Nvidia Treiber 372.54 zum ersten Mal bei mir festgestellt, dass Doom@Vulkan ohne nervige Mikro Ruckler läuft. Das hat sich so geäußert, dass beim normalen langsamen Drehen mit der Maus (auch mit Xbox One Elite Controller getestet) in vielen Szenen (nicht allen) ständig ein permanentes sehr leichtes aber konstantes Stottern beobachtbar war. Die Frametimes waren sehr gut (laut Doom Overlay) und konstant gut. Unter Open GL hatte ich das nicht. Ich konnte das sowohl mit der 980ti, 1080 und Titan XP bestätigen.

Kann es sein, dass es an der neuen Vulkan Version liegt, die mit dem 372.54 mit installiert wird? Ich teste immer mit Gsync + Vsync im Treiber an. Vsync in Doom ist auch an. Hatte es auch ohne Vsync getestet. Das Ergebnis blieb immer das Gleiche.

Hat jemand ähnliche Erfahrungen? Ist das jetzt definitiv gefixxed? Ich hatte leider in Doom@Open GL an einigen wenigen Szenen starke Ruckler und die Frametimes waren teils durch meine CPU richtig mies.

Ich frage, weil ich bisher Doom nie richtig 100% perfekt geniessen konnte und irgendwie traue ich dem zauber noch nicht^^.

iuno

2016-08-19, 16:10:59

Ja, ist bekannt und mit dem neuen Treiber (372.54) behoben.

Robspassion

2016-08-19, 16:24:01

Wow das ist ja klasse. Vielen Dank für die Antwort. Kann ich das auch nachlesen irgendwo?

dargo

2016-08-19, 16:26:40

klar gibt es noch pc exclusives.
Welche? Landwirtschafts Simulator? :D

Kann ich das auch nachlesen irgendwo?
-RFE: Vulkan ability to auto-promote border-less full screen to full-screen exclusive. [1777202]
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=575404

aufkrawall

2016-08-19, 16:29:25

Wow das ist ja klasse. Vielen Dank für die Antwort. Kann ich das auch nachlesen irgendwo?
Könnte der Punkt aus den Release Notes des Treibers sein:
-RFE: Vulkan ability to auto-promote border-less full screen to full-screen exclusive. [1777202]
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=575404
Vorher lief es halt wie im borderless windowed Modus mit triple buffered Vsync, statt Tearing gab es deshalb Lag & Stutter.

Robspassion

2016-08-19, 16:38:11

Stimmt, dass kann es echt sein.

In den Release notes steht auch:

"G-Sync Fullscreen-Mode funktioniert nun ebenso auch unter Vulkan-API"

Lesen müsste man können :freak:

Ex3cut3r

2016-08-19, 16:53:09

Also bei mir bringt Vulkan in 3440x1440 genau 1FPS mehr. :freak:

4770k @ 4,3
GTX 1070 @ 2025/4700 @ 1Volt
16GB DDR3 2133mhz mit scharfen Timings.

Getestet im Gießerei Level, wenn man runter guckt.

aufkrawall

2016-08-19, 16:59:22

Kannst du das auch mal in 720p testen, bzw. die min-fps dabei?
Ich habs leider nicht mehr installiert (die Bosse haben mich im zweiten Durchlauf auf Nightmare einfach zu sehr genervt).

Ex3cut3r

2016-08-19, 17:16:39

Ja kein Ding, mach ich mal heute Abend.

iuno

2016-08-19, 23:51:04

Welche? Landwirtschafts Simulator? :D

Witzbold. Habe überlegt, ob ich überhaupt darauf antworten soll...
Ungefähr jedes ernstzunehmende Strategie- oder Aufbauspiel. Da geht auch technisch einiges, siehe anno oder civ... aber auch total war oder Star cizizen wären gute Beispiele. MM oder esports Spiele, Indies ... :rolleyes:
Nur weil es nicht die typischen franchises mit den meisten Umsätzen und dem größten marketing sind gibt es diese Titel trotzdem :rolleyes: lohnt sich übrigens auch mal sowas anzuschauen

dargo

2016-08-20, 08:13:07

Ich meine natürlich AAA-Titel. Gut... Anno, CiV und Konsorten lasse ich gelten. Daran habe ich tatsächlich nicht gedacht da es nicht mein Genre ist. Den Rest kannst du aber knicken. Star Citizen inbegriffen. Die sollen erstmal die Full raushauen, die Entwicklung zieht sich einfach zu sehr.

Kartenlehrling

2016-08-26, 21:34:34

https://twitter.com/hashtag/CEDEC2016?src=hash

Ist zwar anscheinend ein Mobilgame Engine von Silicon Studio (http://www.siliconstudio.co.jp/en/)aber alles was Vulkan voran bringt ist gut.

www.youtube.com/watch?v=sJ2p982cZFc
Xenko Mutithreading - OpenGL vs Vulkan

Kartenlehrling

2016-08-28, 18:09:09

Das klingt recht vielversprechend.

https://twitter.com/aras_p/status/769651449420713984
So here's my weekend project. SMOL-V: like Vulkan/Khronos SPIR-V, but smaller.

-/\-CruNcher-/\-

2016-08-28, 19:36:12

Kartenlehrling

2016-08-30, 11:21:42

Laut ARM Seite ist der Mali-t760 der im samung s6 verbaut ist Vulkan fähig, samung wirbt natürlich nur mit dem S7 mit voller Vulkan unterstützung.
Nicht das dem Mali-t760 das gleich schicksal erleiden wie Nvidia Kepler :)

The ARM Mali-T760 GPU offers full support for current and next generation APIs, enabling advanced 3D graphics acceleration.
It is Khronos compliant* for OpenGL® ES 3.2/3.1/3.0/2.0/1.1 and Vulkan as well as Microsoft Windows compliant for Direct3D® 11.1.
https://www.arm.com/products/multimedia/mali-gpu/high-performance/mali-t760.php

https://youtu.be/73prhNQwLQs?t=115
Vulkan API Game Experience with the Galaxy S7 at E3 2016

................

Vulkan kann anscheinend auch negativ wirken ...

Deren Snapdragon-800/801-Prozessor wurde in allen genannten Smartphones verwendet und
laut einem Bericht von Slashgear hat Qualcomm beschlossen, keine neuen Treiber für Android 7.0 bereitzustellen.
Grundsätzlich wären die SoCs Snapdragon 800 und 801 leistungsstark genug, um Android 7.0 verwenden zu können.

Doch da Android 7.0 nun auf Vulkan als Grafikschnittstelle setzt,
müsste Qualcomm für die älteren SoCs einen neuen Grafiktreiber entwickeln und hat anscheinend kein Interesse daran.
http://www.gamestar.de/software/google-android/android_70_nougat,760,3301851.html

IC3M@N FX

2016-08-30, 12:37:43

Gibt es Benchmarks mit und ohne Vulkan API bei Android?
Gerade bei schwächeren SoC´s sollte es doch ein Sprung geben ich hab ein Huawei P9 Lite mit Kirin 650 und einer Mali 830 MP2 Version mein Haupthandy ist schnell genug s7 Edge. Ich würde gerne wissen wie es bei schlechteren SoC läuft.......

Botcruscher

2016-08-30, 13:48:43

Vulkan kann anscheinend auch negativ wirken ...

Für den Saftladen kann ja Vulkan jetzt nichts für. Da fehlt schlicht der Zwang zur Offenlegung der Spezifikationen.

Unicous

2016-08-30, 15:31:49

Das hat nichts mit Vulkan zu tun, denn OGL wird weiterhin unterstützt, verstehe auch nicht wie du darauf kommst, Kartenlehrling.

Jedoch verlangt Nougat neuerdings OGL 3.1. und auch das wird nicht von "älteren" Qualcomm GPUs (zumindest treiberseitig) unterstützt. (Nexus 9 unterstützt wohl bislang auch kein Vulkan... aber OGL 3.1. als Beispiel)

Sich auf dabei auf Informationen von Gamestar zu verlassen ist auch keine gute Idee, die haben nämlich keinen blassen Dunst von gar nichts speziell was IT betrifft.

Iruwen

2016-08-30, 16:01:46

Oder auf Heise :D

Troyan

2016-09-03, 09:31:10

-/\-CruNcher-/\-

2016-09-03, 11:47:17

Könnte der Punkt aus den Release Notes des Treibers sein:

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=575404
Vorher lief es halt wie im borderless windowed Modus mit triple buffered Vsync, statt Tearing gab es deshalb Lag & Stutter.

Sollte es im Optimalfall aber eben nicht geben vor allem bei Windows 10

-RFE: Vulkan ability to auto-promote border-less full screen to full-screen exclusive. [1777202]

Heist für mich im Prinzip nichts anderes das Nvidia den border-less Fullscreen ignoriert und anstelle dessen in den Exclusive Fullscreen switched beim Present

Ein workarround warum auch immer.

Könnte das jemand mal mit einem Windows Overlay versuch bestätigen ?

Achill

2016-09-03, 13:24:43

Mal ein Vulkan Update zu nVidia:
Mit dem vorletzten Treiber (Endung 54) hat man für Pascal eine dritte Queue-Familie bereitgestellt, die nur für Compute-Operationen genutzt werden kann. Und laut GPUView ist auch die Hardwarequeue für Compute für Vulkan freigegeben.

Somit sollte der Vulkantreiber nun ungefähr auf dem Niveau von DX12 sein.

Und hier gibt es ein paar Informationen über das generelle Async Compute unter Vulkan auf nVidia-Hardware: https://www.youtube.com/watch?v=XyJlYw4jpgU

Ich glaube der Titel des Videos wurde nicht optimal gewählt. Ich kann aus dem Video (habe es komplett gesehen) nicht entnehmen, wo dort "Async" passiert/unterstützt wird.
=> Es geht primäre um paralleles Compute und wie diese zwischen den Queues aufteilt sowie um Eigenschaften der NV-Hardware und wie man diese gut auslasten werden kann.

Sofern ich bis jetzt nicht komplett auf den Schlauch stand, verstehe ich unter Async Compute etwas ganz anderes:

Asynchrony, in computer programming, refers to the occurrence of events independently of the main program flow and ways to deal with such events. These may be "outside" events such as the arrival of signals, or actions instigated by a program that take place concurrently with program execution, without the program blocking to wait for results. Asynchronous input/output is an example of the latter cause of asynchrony, and lets programs issue commands to storage or network devices that service these requests while the processor continues executing the program. Doing so provides a degree of parallelism.

A common way for dealing with asynchrony in a programming interface is to provide subroutines (methods, functions) that return to their caller an object, sometimes called a future or promise, that represents the ongoing events. Such an object will then typically come with a synchronizing operation that blocks until the operation is completed. Some programming languages, such as Cilk, have special syntax for expressing an asynchronous procedure call.

Examples of asynchrony include the following:

"Ajax", short for "asynchronous JavaScript and XML") is a set of web development techniques utilizing many web technologies used on the client-side to create asynchronous I/O Web applications.
Asynchronous method dispatch (AMD), a data communication method used when there is a need for the server side to handle a large number of long lasting client requests.

Sprich, der aktuelle (primäre) Kontext/Routine X kann zu einen Zeitpunkt z1 eine Subroutine y1 und y2 starten (die irgend etwas macht/berechnet), die X nicht blockieren => daher asynchron. X kann dann weitere Operationen ausführen oder auch weitere Subroutien y3..yN starten.

Zu einen Zeitpunkt z2 benötigt X das Ergebnis von y1 & y2 (Sync-Punkt), hier gibt es dann ein paar Fälle:
- y1 & y2 ist fertig => X kann das Ergebnis übernehmen und fortfahren
- y1 fertig und y2 noch nicht fertig => X kann ggf. mit y1 schon verwenden und/oder muss auf y2 warten
- y1 & y2 nicht fertig => X muss warten

Der große Vorteil der async. Programmierung ist hier, dass das genaue Maßschneidern der SW auf eine bestimmte HW entfällt. Damit meine ich, dass man als SW-Entwickler die Thread/Worker/ShaderCluser-Belegung nicht explizit managen muss sondern leicht parallelisieren kann und damit Latenz vermeidet. Ob die HW wirklich alle Subroutine parallel ausführt oder einige "parkt" ist Aufgabe der HW und vor dem Entwickler versteckt.

In Bezug auf das Video würde ich die Behauptung aufstellen, dass eine Anwendung - wie im Video beschrieben - nur eine HW-Architektur sehr gut auslastet, nähmlich die auf die die SW abgestimmt ist (z.B. 16 Queues, entsprechende SharedMemory) und abweichende HW sich abweichend verhält.

-/\-CruNcher-/\-

2016-09-03, 13:38:20

Richtig erkannt ;)

dargo

2016-09-07, 08:55:44

DxTory V2.0.136 bietet nun Vulkan-Support. :up:

MOD: ID3D12CommandQueue acquisition codes.
ADD: Supported Vulkan.
ADD: Supported wildcard string of ignore setting.
FIX: Problems Dxtory Video to crash.
FIX: Problems DirectX12 capture is stopped.
FIX: Handling of a broken license file.

http://exkode.com/dxtory-log-en.html

rudl

2016-09-21, 19:01:40

... Ich bin gerade enorm begeistert von Vulkan

DOOM Vulkan ...selbst mit nvidia

Phenom II X4 925 2.8 Ghz
Nvidia GTX 970 @PCI-e x16 ...1.0!!!

Ultra quality fast durchgehend über 60fps ;D sehr oft 100+

Lustigerweise hat meine frühere GTX960 2GB selbst auf low oft ziemlich arg geruckelt.
Ich denke aber nicht dass es wegen der reinen rechenleistungt ist sondern eher die kombination aus zu wenig vram und pci-e 1.0

...normalerweise hätte ich nie von einer 960 auf 970 upgegradet,
allerdings musste schnell billiger ersatz her, da die 960 in einem anderen PC verwendung gefunden hat

dildo4u

2016-09-23, 10:46:05

Alte Karte GTX970 1080p Ultra 78fps

http://abload.de/img/vulkangz7s83.png

Neue Karte 1070 SC 1080p Ultra 122 fps

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

Vulkan nutzt die Karte aber nicht wirklich aus geht locker über 2Ghz,Witcher 3 hängt bei 1.85.
Und irgendwie bekomm ich keine Vulkan Screens über druck mehr hin zeigt mir immer das Menü auf dem Screen.

dargo

2016-09-23, 11:27:47

Einfach die neueste DxTory Version nutzen.

Kartenlehrling

2016-09-23, 15:01:47

wieso so umständlich, steams screenshot funktioniert doch auch unter Vulkan?!!

dargo

2016-09-23, 15:22:21

Dann versuch das mal.

Kartenlehrling

2016-09-23, 15:25:10

http://steamcommunity.com/sharedfiles/filedetails/?id=768410494

dargo

2016-09-23, 15:27:16

Dann bist du offenbar einer derjenigen bei denen es geht.

Stebs

2016-09-28, 12:23:06

Der Open-Source RADV Radeon Vulkan Linux Treiber kann nun The Talos Principle korrekt rendern:
http://airlied.livejournal.com/82099.html
Erstaunlich wie schnell da die Fortschritte sind.

Avalox

2016-09-30, 08:59:50

Unity hat die Beta ihres Vulkan Renderers gerade veröffentlicht.

https://blogs.unity3d.com/2016/09/29/introducing-the-vulkan-renderer-preview/

Kartenlehrling

2016-10-04, 18:38:22

https://guidebook.com/guide/78837/event/14488162/
Vulkan Graphics Panel Okt 13th

This panel on Vulkan pulls together graphics experts from across the industry to discuss the present and future of Vulkan, the new generation graphics and compute API.
Vulkan provides high-efficiency, cross-platform access to modern GPUs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms.
Moderated by John McDonald of Valve

Hübie

2016-10-04, 19:33:22

Leider sieht die Teilnehmerliste überwiegend nach mobile gaming aus. Auf dem PC läuft vieles wohl in zu gelenkten Bahnen...

iuno

2016-10-04, 19:37:56

Wo?
Steam hat keine mobile Plattform, Valve macht keine mobile Games, von Croteam ist The Talos Principle (PC), Rolando Caloca war auch auf der SIGGRAPH und hat ueber UE4+VK gesprochen, was ebenfalls den PC betraf.

Hübie

2016-10-04, 20:12:15

Das Wort überwiegend ist dir aufgefallen oder? :D Valve hat eigene Interessen für ihr SteamOS. Ob es da Fortschritte gibt weiß ich nicht, aber die machen ja selber keine Spiele mehr wie es scheint, also ist deren Einfluss erst mal fraglich.
Verstehe irgendwie nicht warum alle DX12 so hinterher rennen, aber Vulkan noch stiefmütterlich behandelt wird...

aufkrawall

2016-10-04, 20:28:08

Epic rennt DX12 doch gar nicht hinterher. Deren Fokus scheint mir momentan eher vom PC wegzudriften, hin zu Android (& damit Vulkan). Ist hoffentlich nur eine Momentaufnahme...

iuno

2016-10-04, 20:34:10

Das Wort überwiegend ist dir aufgefallen oder? :D
4/5 Leuten habe ich aufgezaehlt, der Nvidia-Mann sagt mir nichts. Hast du eine andere Liste?
Valve hat eigene Interessen für ihr SteamOS. Ob es da Fortschritte gibt weiß ich nicht, aber die machen ja selber keine Spiele mehr wie es scheint, also ist deren Einfluss erst mal fraglich.
In der Theorie, ja. Den Eindruck, dass diese Interessen auch wirklich ernsthaft verfolgt werden, habe ich aber eigentlich nicht.

SaschaW

2016-10-05, 10:27:30

4/5 Leuten habe ich aufgezaehlt, der Nvidia-Mann sagt mir nichts. Hast du eine andere Liste?

Jeff Bolz macht ganz viel in Richtung SPIR-V (und GLSL). Seinen Namen findet man auch in ganz vielen OpenGL Extension Dokumenten ;)

Kartenlehrling

2016-10-05, 13:19:04

https://developer.nvidia.com/getting-vulkan-ready-vr
Das "Henne-Ei" -Problem

iuno

2016-10-07, 14:34:00

Der Open-Source RADV Radeon Vulkan Linux Treiber kann nun The Talos Principle korrekt rendern:
http://airlied.livejournal.com/82099.html
Erstaunlich wie schnell da die Fortschritte sind.
radv ist jetzt auch in mesa drin. :up:

Kleiner Hintergrund: Bas Nieuwenhuizen von AMD und Dave Airlie (RedHat, DRM Maintainer) haben zu zweit in ein paar Wochen diesen freien Treiber hochgezogen. Er ist noch nicht konform, wurde aber jetzt schon ins Mesa Projekt aufgenommen. Neben TTP laeuft zumindest auch DOTA schonmal damit. Laut phoronix performt er noch deutlich schlechter als der proprietaere von AMD, aber teils immerhin schon mal besser als die OpenGL Version des jeweiligen Spiels.
Das ist schon auch ein ziemlich eindeutiger Hinweis auf die Komplexitaet eines Vulkan ggue. eines OGL Treibers. Bas hat vielleicht auch Einsicht in den proprietaeren Treiber, Dave hat Erfahrung mit GPUs und der Treiberentwicklung, das gilt aber genauso auch fuer OpenGL. Daher ist das Ganze imho trotzdem beachtlich.

Foobar2001

2016-10-07, 20:11:52

Weil immer so getan wird, als waere NVIDIA bei den unterstuetzten Features so toll.

NVIDIA:
maxPerStageDescriptorInputAttachments: 8
maxPerStageDescriptorSampledImages: 8192
maxPerStageDescriptorSamplers: 4000
maxPerStageDescriptorStorageBuffers: 16
maxPerStageDescriptorStorageImages: 8192
maxPerStageDescriptorUniformBuffers: 12
maxPerStageResources: 24612

AMD:
maxPerStageDescriptorInputAttachments: 4294970000
maxPerStageDescriptorSampledImages: 4294970000
maxPerStageDescriptorSamplers: 4294970000
maxPerStageDescriptorStorageBuffers: 4294970000
maxPerStageDescriptorStorageImages: 4294970000
maxPerStageDescriptorUniformBuffers: 4294970000
maxPerStageResources: 4294970000

Das nervt extrem.

SaschaW

2016-10-07, 20:32:11

Ja, ein paar der Limits sind auf NVIDIA etwas strikt, aber niemand wird pro Stage (!) mehr als 8k Descriptoren für gesampelte Images (Texturen) brauchen. Die Sache mit den max. 64 KB pro UBO ist da was anders, aber wohl dem Design geschultet ist. Die "Limits" von AMD (4294970000) sind ja auch nicht realistisch.

Dafür gibts (zumindest aktuell) nur bei NVIDIA sparse residency, bei AMD fehlt das unter Vulkan noch.

Foobar2001

2016-10-07, 20:48:24

Ja, ein paar der Limits sind auf NVIDIA etwas strikt, aber niemand wird pro Stage (!) mehr als 8k Descriptoren für gesampelte Images (Texturen) brauchen.
Doch. Ich.

Auf AMD kannst du alle Texturen in ein grosses desc set packen und es dynamisch indizieren. Das macht alles einfacher.

Die "Limits" von AMD (4294970000) sind ja auch nicht realistisch.
Das ist kein gutes Argument. Es sagt einfach: So viel wie in den VRAM passt. Und nicht irgendwelche total niedrigen Bullshit-Limits wie bei NVIDIA.

Dafür gibts (zumindest aktuell) nur bei NVIDIA sparse residency, bei AMD fehlt das unter Vulkan noch.
Sparse ist nutzlos auf Windows. Microsoft hat's komplett verkackt mit Windows 10. Ist unfassbar langsam bei den CPU-Updates, ich hab's selber ausprobiert.

Das betrifft aber auch alle anderen APIs.

Hübie

2016-10-07, 23:53:35

Hast du denn deinen NV Kontakt mal gefragt warum, wieso, weshalb solche engen Grenzen gesetzt werden und ob man das nicht ausbauen bzw. umbauen kann?

Foobar2001

2016-10-08, 00:07:07

Das sind Hardware-Limits. Selbst in Pascal.

Hübie

2016-10-08, 00:12:33

Dann sind das bei AMD aber doch keine realistischen Werte. Sieht mir eher danach aus, als würde es dort die Hardware oder der Treiber dann besser regeln, oder nicht?

Edit: Nach dem Motto: "Wirf mir alles entgegen, ich handle das schon"

Foobar2001

2016-10-08, 00:30:13

Doch, sind sie, solange der VRAM nicht ausgeht. Hab ich oben schon geschrieben. Nein, das sind echte Hardware-Limits bei NVIDIA, keine Softwareprobleme.

NVIDIA kann nur 64KiB UBOs und alles was uniform und schnell sein soll muss da durch.

Hübie

2016-10-08, 00:37:34

Das ist dann in der Tat nervig. Aber damit wird man sich wohl immer herumschlagen müssen.

Locuza

2016-10-10, 11:59:49

Update vom 10.10.16:

Wie sich inzwischen herausgestellt hat, handelte es sich bei den Angaben im Originalartikel um Fehlinformationen eines Intel-Mitarbeiters. Ein gewisser Intel-Entwickler "Michael C.", der unter anderem für die Blog-Einträge von neuen GPU-Treibern verantwortlich ist, gibt an, dass die Vulkan-Unterstützung ab Skylake weiterhin für Windows geplant sei. Aktuell veröffentliche man Beta-Treiber mit Vulkan-Support allerdings nur für Entwickler innerhalb der Game Developer Zone. Finale Vulkan-Treiber sollen schließlich auch wieder für Endnutzer erscheinen, einen Termin gibt es allerdings noch nicht.
http://www.pcgameshardware.de/Vulkan-Software-261755/News/Intel-GPUs-Windows-Support-1204208/

*clap clap clap*

y33H@

2016-10-10, 12:02:54

Hübie

2016-10-10, 13:21:35

Intel und Treiber... Ist etwa so wie ich und kochen. Das wird nix. :D

gmb

2016-10-10, 13:40:15

Es fehlt der Wille. Die alte Generation wird links liegen gelassen. Bestes Beispiel ist Kabylake, bekommt OpenCL 2.1 support im Gegensatz zu Skylake. Die GPU bleibt gleich, es ist rein marktpolitisch. Womöglich wartet Intel auf Gen10, die dann offiziell Vulkan bekommt. Aber dass Intel Vulkan irgendwann bringt, war doch klar.

SaschaW

2016-10-10, 13:57:51

Ganon

2016-10-10, 14:42:26

Grade im Hinblick auf den guten Linux-Treiber schade was Intel unter Windows (nicht) macht. Unter Ubuntu (mit MESA) laufen auf meinem Ultrabook mit Haswell fast alle meine Vulkan Demos (sofern die Hardware die genutzten Features verwendet), und wenn ich da nen Bug melde wird der i.d.R. auch recht flott gefixt.

Ja es geht voran, wenn auch langsam. Das Tolle ist der Einblick in die Entwicklung. Kein Rätselraten was der Treiber nun genau kann oder was irgendwo fehlt. Man guckt einfach in die TODO im Source:

https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/TODO

Achill

2016-10-11, 10:23:37

Ja es geht voran, wenn auch langsam. Das Tolle ist der Einblick in die Entwicklung. Kein Rätselraten was der Treiber nun genau kann oder was irgendwo fehlt. Man guckt einfach in die TODO im Source:

https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/TODO

Der RADV Radeon Vulkan Driver hat es vor 4 Tagen auch ins mesa repo geschafft. Mir gefällt die GitHub Sicht besser: https://github.com/mesa3d/mesa/tree/master/src/amd/vulkan (gibt es aber auch hier (https://cgit.freedesktop.org/mesa/mesa/tree/src/amd/vulkan) bei freedesktop.org)

Bridgman (AMD) hat im phoronix Forum auch angedeutet, dass man die Strategie ändern könnte und direkt in das neue Projekt contributed, da sich die Öffnung des eigenen Treibers wohl noch hinzieht und dieser Weg evtl. leichter wäre.

radv ist jetzt auch in mesa drin. :up:

Kleiner Hintergrund: Bas Nieuwenhuizen von AMD und Dave Airlie (RedHat, DRM Maintainer) haben zu zweit in ein paar Wochen diesen freien Treiber hochgezogen. Er ist noch nicht konform, wurde aber jetzt schon ins Mesa Projekt aufgenommen. Neben TTP laeuft zumindest auch DOTA schonmal damit. Laut phoronix performt er noch deutlich schlechter als der proprietaere von AMD, aber teils immerhin schon mal besser als die OpenGL Version des jeweiligen Spiels.
Das ist schon auch ein ziemlich eindeutiger Hinweis auf die Komplexitaet eines Vulkan ggue. eines OGL Treibers. Bas hat vielleicht auch Einsicht in den proprietaeren Treiber, Dave hat Erfahrung mit GPUs und der Treiberentwicklung, das gilt aber genauso auch fuer OpenGL. Daher ist das Ganze imho trotzdem beachtlich.

iuno hatte es schon geschrieben ... :D

d2kx

2016-10-12, 15:43:43

Valve wird in den kommenden zwei Tagen auf den SteamDevDays einige HTC Vive/VR Demos unter SteamOS/Linux zeigen, die Vulkan als API benutzen.

iuno

2016-10-13, 13:35:37

hab gerade wenig Zeit, gibt es eine Seite, die die Infos von den SteamDevDays gut zusammenfasst?

DinosaurusRex

2016-10-14, 07:55:12

Steam hat keine mobile Plattform, Valve macht keine mobile Games

Genau dieser Umstand ist mir unverständlich. Das Konzept von Steam ist prädestiniert für einen mobilen Ableger. Der Steam Store ist jetzt schon proppenvoll mit Spielen, die ein Zyniker als Shovelware bezeichnen würde. Die Kundschaft ist es also gewohnt, Spiele fernab von AAA Budgets angeboten zu bekommen. Und Steam funktioniert seit jeher unabhängig von der Hardware der Kunden.

Die Entwicklung von Steam OS und Steam Machines waren Totgeburten und die reinste Zeitverschwendung. Stattdessen hätte sich Valve auf ein Steam To Go oder sowas konzentrieren sollen. Ich glaube gerade bei Mobile Games würde dieses Steam Sale-Konzept fantastisch funktionieren: Dann schnüren die halt ein Bundle mit zehn Spielen oder so und verkaufen das für 5 Euro.

Valve hat eine enthusiastische Community und könnte für die Studios und Publisher eine Brücke in die Welt der Smart Devices schlagen. Wenn sie es nicht tun, wird es jemand anderes machen. An Smart Devices führt kein Weg mehr vorbei. Wer das verschläft, wird mittelfristig richtig Probleme bekommen. Ich verstehe nicht, warum Valve seine hervorragende Ausgangsposition nicht nutzt und stattdessen das Geld für unnötigen Scheiß rauswirft.

Foobar2001

2016-10-14, 08:06:03

Beide Mobile-Oekosysteme (Android und iOS) erlauben keine anderen Stores.

DinosaurusRex

2016-10-14, 08:10:00

Dann machen sie es halt wie Spotify mit Abo oder sowas. Oder verteilen im PC Store Gummipunkte, die man im Mobile "Store" gegen Spiele eintauschen kann. Da gibt es genug Möglichkeiten.

So ein Abomodell wäre vermutlich gar nicht so verkehrt. Die Spieler kennen das und haben es angenommen. 5 Euro im Monat und du kannst alle Titel unbegrenzt spielen. Für den PC ist im Preis dann auch ein Bonus mit inbegriffen und alle sind happy.

Foobar2001

2016-10-14, 08:39:22

Nein, gibt es nicht. Die einzige Bezugsquelle fuer signierte Apps ist der offizielle Store von Google oder Apple.

StefanV

2016-10-14, 08:58:00

Beide Mobile-Oekosysteme (Android und iOS) erlauben keine anderen Stores.
Du hast die dritten vergessen:
Microsoft Windows Mobile...

Aber ich glaube kaum, dass es dort anders ausschaut, oder?

Demirug

2016-10-14, 09:33:12

Nein, gibt es nicht. Die einzige Bezugsquelle fuer signierte Apps ist der offizielle Store von Google oder Apple.

Bei Android kann man alternative Stores installieren. Gibt zum Beispiel einen von Amazon.

Du hast die dritten vergessen:
Microsoft Windows Mobile...

Aber ich glaube kaum, dass es dort anders ausschaut, oder?

Sideloading ist dort in einem sehr begrenzten Umfang möglich. Das ist aber nur was für Hobbyisten. Darauf kann man kein Geschäftsmodell aufbauen.

So ein Abomodell wäre vermutlich gar nicht so verkehrt. Die Spieler kennen das und haben es angenommen. 5 Euro im Monat und du kannst alle Titel unbegrenzt spielen. Für den PC ist im Preis dann auch ein Bonus mit inbegriffen und alle sind happy.

Abomodelle sind für den Betreiber kompliziert wenn man Content von dritten anbieten möchte den man nicht besitzt.

Zudem fürchte ich das Apple da nicht mitspielen wird. Spotify lebt da schon in einem ständigen Kriegszustand. Wenn jemand sowas für Spiele (die Haupteinnahmequelle im App Store) machen will wird Apple die ganz schweren Geschütze auffahren. Entsprechend geht auch niemand das Risiko ein da auch nur einen Dollar in die Entwicklung eines solchen Systems zu investieren.

Hübie

2016-10-14, 10:05:54

Du hast die dritten vergessen:
Microsoft Windows Mobile...

Aber ich glaube kaum, dass es dort anders ausschaut, oder?

Man kann Apps von extern installieren (so ist z.B. ein Pokemon Go Client möglich) , aber einen anderen Store gibt es einfach noch nicht und wird es wohl auch niemals geben. Microsoft müsste Milliarden investieren um ein stabiles Ökosystem aufzubauen. Das ist denen zu riskant. Da rennen die Aktionäre davon. :biggrin:

Bei Android gibt es sehr wohl verschiedene Stores. Samsung und Sony haben doch welche. Ebenso der von Demirug genannte Amazon-Store bietet eigens signierte Apps an. Ein System für die apk Distribution dürfte auch nicht allzu schwierig zu basteln sein.

Foobar2001

2016-10-14, 20:18:43

Bei Android kann man alternative Stores installieren. Gibt zum Beispiel einen von Amazon.
Ja, macht aber niemand. Und man muss in die Entwickleroptionen und die Signaturpruefung ausschalten etc.

Screemer

2016-10-14, 21:39:13

Ja, macht aber niemand. Und man muss in die Entwickleroptionen und die Signaturpruefung ausschalten etc.
Also amazon underground lässt sich ganz einfach mit deaktivieren des schutzes für externe apks installieren. Aktuelle androidversion versionen fragen sogar jedes mal nach. Da muss man in den entwickler optionen gar nix deaktivieren.

iuno

2016-10-14, 23:39:54

"niemand" wuerde ich jetzt auch nicht sagen. Und wo es schon aufkam, sei es mir erlaubt: sicherlich sind das mehr Nutzer als Windows hat ;D
Die Leute klicken sich ueberall durch. Amazon hat z.B. eine billige Anleitung dabei. Das waere doch absolut kein Problem, allerdings braucht halt auch keiner Steam auf dem Handy, wenn man mal ehrlich ist.

kruemelmonster

2016-10-27, 01:32:07

Ashes of the Singularity bekommt womöglich schon mit dem nächsten Update Support für Vulkan:

I am hoping that version 1.5 will arrive before Halloween.
...
## Vulkan ##

This is now working in our internal builds! This might show up in 1.5. AMD is providing a lot of assistance to us in getting Vulkan support so please be sure to give some kudos and credit to AMD for Vulkan in PC gaming. It'll run great on any GPU that supports Vulkan.

http://steamcommunity.com/app/228880/discussions/1/350543389015715216/

DX12 vs Vulkan, Round 1, Fight!

Locuza

2016-10-27, 02:00:41

Sehr cool. :D
Auch ein interessanter Punkt:

## Performance ##

Hopefully some of you noticed the significant performance boost in the September update. We are continuing down that path with version 1.5.

Einfach nur als Randnotiz, dass die alten Performancewerte sich möglicherweise stark verändert haben.
Hoffentlich gibt es einen schönes Update von CB dazu.

fondness

2016-10-27, 09:26:56

AMD is providing a lot of assistance to us in getting Vulkan support so please be sure to give some kudos and credit to AMD for Vulkan in PC gaming. It'll run great on any GPU that supports Vulkan.

Na hoffentlich rentiert sich der gute Dev-Support mit dem eintreten für offene Standards auch mal.

dargo

2016-10-27, 09:32:07

Finde es erstaunlich, dass man dafür noch Ressourcen investiert wo es schon DX11 und DX12 gibt. Hätte ich so jetzt nicht erwartet. Ob es mit Vulkan auch mal Shader Instrics gibt? :naughty:

Stebs

2016-10-27, 15:59:20

Ob es mit Vulkan auch mal Shader Instrics gibt? :naughty:Gibt es schon.
Bei AMD sind das afaik diese 3 Extensions:

AMD_shader_ballot
AMD_shader_trinary_minmax
AMD_shader_explicit_vertex_parameter

http://gpuopen.com/gcn-shader-extensions-for-direct3d-and-vulkan/
PS. AFAIR werden diese von Doom ja auch schon genutzt...

Bei Nvidia sind die "richtigen" Vulkan Extensions noch in Arbeit, da es sie aber mit OpenGL schon gibt, kann man sie mit GLSL via VK_NV_glsl_shader im Prinzip jetzt schon nutzen:

"The GLSL extensions discussed above are already supported by our Vulkan drivers via VK_NV_glsl_shader, which makes them available for experimentation today!

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

https://developer.nvidia.com/reading-between-threads-shader-intrinsics

Screemer

2016-10-27, 21:01:51

Ihm ging es wohl eher darum ob die im Vulkanrenderer dann auch genutzt werden. In dx11/12 wären sie ja nutzbar, werden es aber nicht.

Foobar2001

2016-10-27, 21:31:54

Beachtet, dass AMD ein Superset von den NVIDIA-Intrinsics unterstuetzt. Nicht alles was auf AMD Vorteile bringt ist auf NVIDIA portierbar.

dargo

2016-10-27, 21:56:44

Gibt es schon.

Du hast mich da falsch verstanden. Ich meine natürlich im kommenden Vulkanrenderer für AotS.

d2kx

2016-10-27, 22:08:33

Deus Ex: Mankind Divided bekommt einen Vulkan-Renderer in H1 2017. Angedacht für den Linux-Port, ich würde Unterstützung für die Windows-Variante allerdings nicht ausschließen.

dargo

2016-10-27, 22:12:03

Hübie

2016-10-27, 22:25:20

Deus Ex: Mankind Divided bekommt einen Vulkan-Renderer in H1 2017. Angedacht für den Linux-Port, ich würde Unterstützung für die Windows-Variante allerdings nicht ausschließen.

Das klingt ja super. Legt den Schluß nahe, dass es für Devs einfacher ist auch noch einen Vulkan-Renderer zu implementieren. Je breiter Vulkan streut, desto besser für den Endkunden.
Jetzt frage ich mich gerade ob es Doom 2016 eigentlich für Linux gibt. :redface: DX:MD hab ich noch gar nicht gekauft. Dann warte ich weiter.

dargo

2016-10-27, 22:39:39

Das klingt ja super. Legt den Schluß nahe, dass es für Devs einfacher ist auch noch einen Vulkan-Renderer zu implementieren.

Ich denke eher der Hauptgrund ist halt Linux. Wenn aber davon auch was für die Windows-Version "abfällt" warum nicht? :) Aber bitte nicht wieder so eine Baustelle wie bei DX12. :cool:

Je breiter Vulkan streut, desto besser für den Endkunden.

Ich habe das bis heute nicht verstanden. Worum gehts euch eigentlich? Windows 10 boykottieren? Wir haben schon fast 2017. Ab 2020 sollte es keine Sicherheitsupdates für Windows 7 geben und damit ist Win7 imho auch tot.
https://support.microsoft.com/de-de/help/13853/windows-lifecycle-fact-sheet

Was bleibt einem übrig? Auf Windows 8.1 zu wechseln? Glaube ich kaum denn auch hier wird der Support selbstverständlich kürzer aufrecht erhalten als bei Windows 10. Und sehr unbeliebt ist/war Windows 8.x auch noch. Und das plötzlich innerhalb 1-2 Jahre alle Games nur noch für Linux kommen ist doch etwas realitätsfern. ;)

Foobar2001

2016-10-27, 22:48:06

Hübie

2016-10-27, 22:53:57

Ich denke eher der Hauptgrund ist halt Linux. Wenn aber davon auch was für die Windows-Version "abfällt" warum nicht? :) Aber bitte nicht wieder so eine Baustelle wie bei DX12. :cool:

Ich habe das bis heute nicht verstanden. Worum gehts euch eigentlich? Windows 10 boykottieren? Wir haben schon fast 2017. Ab 2020 sollte es keine Sicherheitsupdates für Windows 7 geben und damit ist Win7 imho auch tot.
https://support.microsoft.com/de-de/help/13853/windows-lifecycle-fact-sheet

Was bleibt einem übrig? Auf Windows 8.1 zu wechseln? Glaube ich kaum denn auch hier wird der Support selbstverständlich kürzer aufrecht erhalten als bei Windows 10. Und sehr unbeliebt ist/war Windows 8.x auch noch. Und das plötzlich innerhalb 1-2 Jahre alle Games nur noch für Linux kommen ist doch etwas realitätsfern. ;)

Wen meinst du mit "euch"? :| Mir persönlich kann es egal sein, da ich WinXP, XP64, 7, 8.1 und 10 jeweils in der höchsten Stufe legal besitze.
In Bezug auf Vulkan geht es mir darum dass diese API plattformunabhängig ist und so Portierungen wieder erleichtert, was Absatz fördert und Qualität langfristig erhöht. Diese Unfälle mit DX12 reichen langsam. Ich verstehe zu wenig von der Materie um eine qualifizierte Aussage bezüglich Aufwand für die Programmierung des Renderbackends, aber der Tenor ist das es weniger restriktiv und flexibler ist.
Windows kann gerne wer anders blockieren. Aber UWP oder auch DX12 haben bisher kein positives Bild hinterlassen. Daher Vulkan. Freuen sich sogar die Linuxer. ;)

dargo

2016-10-27, 23:05:18

Wen meinst du mit "euch"?

Na alle die nichts von Windows 10 wissen wollen. Hatte zuerst gedacht du gehörst auch dazu, hab mich dann geirrt.

In Bezug auf Vulkan geht es mir darum dass diese API plattformunabhängig ist und so Portierungen wieder erleichtert, was Absatz fördert und Qualität langfristig erhöht.

Naja... das mit der Plattformunabhängigkeit ist so eine Sache. Gibts die wirklich? Zb. gibt es keinen Vulkansupport für Windows XP. Der Grund ist möglicherweise aber auch, dass es für dieses OS eben auch keinen Support von Microsoft mehr gibt. Keine Ahnung... Wobei, Mantle setzte auch schon Windows 7 voraus. Irgendwelche Limits bezüglich OS muss es also geben.

Diese Unfälle mit DX12 reichen langsam. Ich verstehe zu wenig von der Materie um eine qualifizierte Aussage bezüglich Aufwand für die Programmierung des Renderbackends, aber der Tenor ist das es weniger restriktiv und flexibler ist.
Windows kann gerne wer anders blockieren. Aber UWP oder auch DX12 haben bisher kein positives Bild hinterlassen. Daher Vulkan. Freuen sich sogar die Linuxer. ;)
Ich machs mal kurz. Alle erschienenen und kommenden XBox Multititel werden ausschließlich für Windows 10 und UWP kommen. Da führt kein anderer Weg vorbei. Wer auf diese Spiele verzichten kann den wird das sicherlich nicht stören.

Foobar2001

2016-10-27, 23:36:30

Du meinst alle Titel von Microsoft. Niemand zwingt Dritthersteller, die nur Xbox und Windows unterstuetzen den Windows Store zu verwenden.

dargo

2016-10-27, 23:44:32

Ja, natürlich.

Locuza

2016-10-28, 02:53:18

Quelle? Google findet nichts ausser irgendeine daemliche Spekulation. Wahrscheinlich einfach ein D3D11-Wrapper auf OpenGL.
Sadly the upcoming Deus Ex Linux port will only be using OpenGL while the macOS port is using Metal and the Windows game supports Direct3D 12. But on the bright side, Feral Interactive is planning for Vulkan Linux game ports in the first half of next year.

Feral confirmed via a Twitch stream today of Deus Ex and on Twitter, "Linux gamers! We just announced, live on Twitch, that we are looking towards Vulkan implementation in the first half of next year."

The Deus Ex release next week will be making use of OpenGL.

No word on any H1'2017 game plans where they are currently plotting to make use of Vulkan.
http://phoronix.com/scan.php?page=news_item&px=Feral-Vulkan-H1-2017
https://twitter.com/feralgames/status/791711184818999296

Es scheint leider nicht konkret durch, ob damit schon Deus Ex gemeint ist oder allgemein einfach nur zukünftige Titel.

Hübie

2016-10-28, 03:21:57

Wenn man DX:MD in VR will ist es vielleicht flexibler und einfacher, das mit Vulkan umzusetzen. Zumindest stelle ich es mir so vor, nachdem was man so liest. Auch die Plattformportierung könnte weniger Arbeit erfordern. Wieso man jetzt OGL, D3D12, Metal und Vulkan durchkaut begreif ich da nicht. Metal - okay. Apple only. Aber Rest kann man durch Vulkan durchgängig ersetzen. :confused:

Naja... das mit der Plattformunabhängigkeit ist so eine Sache. Gibts die wirklich? Zb. gibt es keinen Vulkansupport für Windows XP. Der Grund ist möglicherweise aber auch, dass es für dieses OS eben auch keinen Support von Microsoft mehr gibt. Keine Ahnung... Wobei, Mantle setzte auch schon Windows 7 voraus. Irgendwelche Limits bezüglich OS muss es also geben.

Android, Linux und Windows hast du schon mal. WinXP geht aus vielerlei Gründen nicht, die mit dem ineffizienten Thread-Scheduler bis hin zum Treibermodel reichen.

Ich machs mal kurz. Alle erschienenen und kommenden XBox Multititel werden ausschließlich für Windows 10 und UWP kommen. Da führt kein anderer Weg vorbei. Wer auf diese Spiele verzichten kann den wird das sicherlich nicht stören.

Wieviel werden das sein? 10 Titel? Wieviel davon werden gut sein? 5? Wieviel werden UWP vernünftig umsetzen? 2? Wieviel werden mit D3D12 schneller sein? 0. ;D Ich male das mal schwarz.

Locuza

2016-10-28, 03:41:59

Die PC-Version hat Nixxes übernommen, welche DX11 und DX12 umgesetzt haben.
Die Mac und Linux Version mit Metal, OGL und später Vulkan übernimmt aber Feral Entertainment.
Unterschiedliche Studios, unterschiedliche Plattformen, unterschiedliche Zeiträume.

Vulkan braucht nach wie vor ein robustes HLSL--> SPIR-V Frontend und Multi-GPU Support, um eine gute Alternative hinsichtlich diverser DX12 Bemühungen zu sein.

iuno

2016-10-28, 07:38:06

Es scheint leider nicht konkret durch, ob damit schon Deus Ex gemeint ist oder allgemein einfach nur zukünftige Titel.
Genau, ich halte es aber schon fuer wahrscheinlich. Larabel von Phoronix hat schon ein paar mal nachgefragt und sie wollten das bisher weder bestaetigen noch dementieren. Das alleine heisst zwar noch nichts, aber man ist von deren Ports eh gewohnt, dass sie schlecht laufen. Zu verlieren haetten sie also nichts, wenn sie es gleich dementiert haetten.
Und da es eh schon eine d3d12 Version gibt, koennte das mit einem Wrapper auch halbwegs funktionieren.
Allerdings wuerde ich es SE auch zutrauen, das den originalen Dev, also Eidos, machen zu lassen. SE laesst sich inzwischen schon einige Spiele von Feral machen und sieht auch dass die Qualitaet nichts ist. Umsonst ist es natuerlich trotzdem nicht. Sollte also Eidos das Ding auf Vulkan umbauen, und Feral vielleicht (falls noetig) den Rest, koennte das auch auf Linux mal ganz gut werden.
Die selbe Hoffnung habe ich auch nocht fuer ROTTR...

Locuza

2016-10-28, 07:54:06

Eidos macht noch nicht einmal selber die PC-Versionen, wieso sollten ausgerechnet die sich extra um Linux und Vulkan kümmern?
Feral ist dabei wieder beauftragt worden für Deus Ex, also "sieht" SE weiterhin keine Nöten etwas zu ändern.

iuno

2016-10-28, 07:56:02

dargo

2016-10-28, 08:17:52

Wieviel werden das sein? 10 Titel?
Keine Ahnung, das wird die Zukunft zeigen. Bisher sind afaik 7 Titel mit UWP gekommen von denen eins ausschließlich DX11 war und zwei auch für Steam kamen.

Locuza

2016-10-28, 08:19:43

Ich habe nur eben bei wiki nachgeschaut. Wer ist dann der "richtige" Entwickler, wenn nicht Eidos? Ich sage nicht, dass der dev sich um Linux kuemmern soll, sondern um deren Engine/Renderer. Davon koennte der Linux Port ja nur nebensaechlich profitieren.
Feral macht in erster Linie Mac Ports -> OGL
Eidos Montreal und andere westliche Studios von SE kümmern sich aber intern schon lange häufig nur um die Konsolen-Fassungen und selbst dort nicht immer alle, die Windows-Versionen werden dann schon praktisch traditionell von Nixxes übernommen.
Deus Ex: Human Revolution, Tomb Raider, Hitman Absolution, Thief, Rise of the Tomb Raider und Deus Ex: Mankind Divided sind alle von Nixxes umgesetzt worden.
Und die Rise of the Tomb Raider x360 Umsetzung und die für die PS4 kam auch von Nixxes und davor die Definitive Edition von Tomb Raider für die PS4/Xbox One.

Bezüglich Mac/Linux hat Nixxes entweder nicht das gleiche Expertise wie Feral, die Zeit und Manpower für solche Projekte oder sie sind nicht so günstig und SE spart sich lieber etwas Geld für Nischenumsetzungen.

Die Engine und der Renderer stehen ja sowieso grundlegend fest, die konkreten API-Anpassungen werden dann eben outsourced, zusammen mit weiteren Plattform spezifischen Anpassungen für Eingabe, Audio, UI und ähnlichem.

Lurtz

2016-10-28, 09:06:45

Deus Ex: Mankind Divided bekommt einen Vulkan-Renderer in H1 2017. Angedacht für den Linux-Port, ich würde Unterstützung für die Windows-Variante allerdings nicht ausschließen.
:massa:

Ich habe das bis heute nicht verstanden. Worum gehts euch eigentlich? Windows 10 boykottieren?
Dass DX12 bisher ein einziger Flop ist, reicht nicht als Grund?

Mal davon abgesehen ist Vulkan auf wesentlich mehr Plattformen einsetzbar und allein schon deshalb vorzuziehen.

dargo

2016-10-28, 09:16:52

Dass DX12 bisher ein einziger Flop ist, reicht nicht als Grund?

Was für Flop? Wo ist zb. ein GoW 4 trotz UWP gefloppt? :|

Hier wird ja ständig so getan, als ob es an der API läge. Wie oft muss man noch wiederholen, dass es außerhalb von UWP (hier kommen andere Probleme ins Spiel) am Hirnschmalz der Entwickler liegt? Nur weil ein Spiel bisher mit Vulkan erschienen ist welches überzeugt ist Vulkan das nonplusultra? Du stellst dir das etwas zu einfach vor.

Edit:
Auch wenn es so klingt möchte ich hierbei natürlich nicht ausschließlich die Schuld den Entwicklern in die Schuhe schieben. Wenn ein Publisher sagt wir müssen zum Zeitpunkt X fertig werden dann rückt eben ein DX12 Renderer nach hinten. Es gibt genug Baustellen in Spielen außerhalb der API. Bestes Beispiel aktuell Mafia 3. Das Spiel hat nur DX11 und ist trotzdem völlig unfertig erschienen.

Lurtz

2016-10-28, 09:24:06

Was für Flop? Wo ist zb. ein GoW 4 trotz UWP gefloppt? :|

Hier wird ja ständig so getan, als ob es an der API läge. Wie oft muss man noch wiederholen, dass es außerhalb von UWP (hier kommen andere Probleme ins Spiel) am Hirnschmalz der Entwickler liegt? Nur weil ein Spiel bisher mit Vulkan erschienen ist welches überzeugt ist Vulkan das nonplusultra? Du stellst dir das etwas zu einfach vor.
Es ist nicht das nonplusultra, aber im Gegensatz zu DX12 besteht wenigstens noch Hoffnung.
GoW 4 zeigt jetzt auch nichts, was mit DX11 nicht möglich gewesen wäre.

Zudem kann man DX12 nicht von den politischen Entscheidungen Microsofts trennen, die es noch mehr runterziehen.

dargo

2016-10-28, 09:32:57

Es ist nicht das nonplusultra, aber im Gegensatz zu DX12 besteht wenigstens noch Hoffnung.

Na dann hoffe mal weiter. :biggrin:

GoW 4 zeigt jetzt auch nichts, was mit DX11 nicht möglich gewesen wäre.

Aha... das kannst du sicherlich auch näher erläutern.

Hübie

2016-10-28, 09:34:39

Gerade bei GoW4 kann man doch gar keine Vergleiche mehr zu D3D11 machen. Das war bisher meistens schneller bis gleichschnell und / oder lieferte bessere Frametimes. Hat sich nun in einigen Titeln mit Patches geändert oder wurde zumindest abgeschwächt.

N0Thing

2016-10-28, 10:18:09

Was für Flop? Wo ist zb. ein GoW 4 trotz UWP gefloppt? :|

Er hat weder was zu GoW4 geschrieben noch zu UWP. Es gibt ja ein paar Spiele, die kein UWP benötigen und sowohl DX11 als auch DX12 bieten. Und in keinem dieser Spiele erreicht die DX12-Version das, was man sich von DX12 versprochen hat. Ob es nun an den Entwicklern liegt, oder daran, dass eine simple Portierung deutlichere Verbesserungen unmöglich macht, ist für die Aussage an sich, dass DX12 bisher nicht überzeugen konnte, unerheblich.

Wenn die Entwickler ihre Engines generell auf eine low level API umstellen, würde sich Vulkan dank der Kompatibilität zu mehreren Betriebssystemen anbieten und damit meine ich auch mehrere Windows-Versionen. Bis 2020 ist es noch eine Weile hin.

Arcanoxer

2016-10-28, 10:48:26

Dass DX12 bisher ein einziger Flop ist, reicht nicht als Grund? Das blicken unsere Windows 10 Experten nicht.
Aber was soll man erwarten wenn man sich das sogar freiwillig antut?

Um mal wieder zur topic zu kommen...
Deus Ex: Mankind Divided bekommt mit Sicherheit keinen Windows Vulkan Support, wenn Feral für den port verantwortlich ist.

Locuza

2016-10-28, 10:59:47

Arcanoxer

2016-10-28, 11:12:31

Was vermutlich auch niemanden traurig machen wird, wenn man sich die DX11 vs. DX12 Ergebnisse anschaut.
Es wäre eher verwunderlich, wenn Vulkan gegenüber DX11 nennenswerte Verbesserungen aufzeigen würde.Die Qualität des Vulkanports wird sich gegen OpenGL messen müssen.
DX12 wird man hoffentlich nicht als Referenz nehmen. ;)

Locuza

2016-10-28, 11:24:34

Im direkten Vergleich unter dem selben Betriebssystem ja, aber auch Vergleiche mit Windows und DX können angestellt werden.
Das wäre ja dann nur noch extra interessant, Windows + DX vs. Linux und Vulkan ;)

dargo

2016-10-28, 12:04:50

Er hat weder was zu GoW4 geschrieben noch zu UWP. Es gibt ja ein paar Spiele, die kein UWP benötigen und sowohl DX11 als auch DX12 bieten. Und in keinem dieser Spiele erreicht die DX12-Version das, was man sich von DX12 versprochen hat.
Das ist eine glatte Lüge.

MuLuNGuS

2016-10-28, 12:32:12

N0Thing

2016-10-28, 12:34:20

Das ist eine glatte Lüge.

Nein, er hat wirklich weder etwas zu GoW4 noch zu UWP geschrieben, es gibt definitiv Spiele, die kein UWP benötigen und es gibt Spiele, die sowohl DX11 als auch DX12 bieten und mir ist kein Spiel bekannt, das die Erwartungen in DX12 erfüllt hat. Für eine Lüge müsste ich bewusst die Unwahrheit sagen. Aber anstatt dich so aggressiv zu äußern, könntest du ja einfach Beispiele bringen, wo zumindest deine Erwartungen an DX12 erfüllt wurden.

dargo

2016-10-28, 12:44:56

Iruwen

2016-10-28, 13:13:21

Der Fehler ist, dass die Spiele zum Release unfertig sind.

fondness

2016-10-28, 13:37:18

Der Fehler ist, dass die Spiele zum Release unfertig sind.

Der DX12 Sticker ist eben gutes Marketing, sodass für viele time to market vor Qualität geht. Das ist aber kein DX12 Problem per se. Dazu ist auch noch ein gewisser Lernprozess bei vielen Entwicklern nötig.

Arcanoxer

2016-10-28, 14:34:15

Aber anstatt dich so aggressiv zu äußern, könntest du ja einfach Beispiele bringen, wo zumindest deine Erwartungen an DX12 erfüllt wurden.+1
Gibt es aber nicht.

dargo

2016-10-28, 14:59:28

Der Fehler ist, dass die Spiele zum Release unfertig sind.
Absolut... allerdings war das vor DX12/Vulkan auch schon bei einigen Games der Fall.

N0Thing

2016-10-28, 16:36:18

Was hatte Microsoft versprochen? Bis zu 50% im CPU-Limit.
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11158521&postcount=3973

Hätte Ex3cut3r eine schnellere GPU wären es sicherlich mehr als 25%. Troyan hatte afaik was von 37% gesprochen. Musst du mal im DX12-Thread suchen. Das alles mit einer Geforce. Bei Radeon sollte der Vorteil noch größer ausfallen. Wenn ich Langerweile habe kann ich mir die entsprechenden Szenen anschauen. Der Fehler den ihr macht... ihr schaut euch immer nur unfertige Spiele zum Release an.

Das schaut in der Tat gut aus. Allerdings warst du damals selber nicht sonderlich begeistert von dem Ergebnis: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11159113&postcount=3982

Ich verfolge durchaus die Tests und Benchmarks, die im Verlauf der Zeit mit aktuellen Patches und Treibern durchgeführt werden und da war auch bei Tomb Raider bisher der Tenor, dass sich DX12 nicht deutlich besser präsentiert als DX11. Das mag an den Savegames liegen, die von den Redaktionen verwendet werden, oder dass sich mit den letzten Treibern und eventuellen Updates fürs Spiel nochmal etwas getan hat und die letzten Tests von den Hardwareseiten inzwischen ein paar Monate alt sind.

Ich habe jetzt noch einen Test vom Juli diesen Jahres gefunden, wo man auch einen deutlichen Unterschied zwischen DX11 und DX12 sehen kann, besonders auffällig bei den Minimum FPS, also schlagen da vermutlich die Vorteile im CPU-Limit durch. Leider habe ich keine Angabe über die verwendete Benchmarkstelle gesehen, deshalb vermute ich, dass der integrierte Benchmark zum Einsatz kam.

https://www.overclock3d.net/reviews/gpu_displays/rise_of_the_tomb_raider_directx_12_performance_update/5

Ein DX12 Roundup am Ende des Jahres oder Anfang nächsten Jahres wäre mal interessant, um den aktuellen Stand der Dinge sehen zu können.

dargo

2016-10-28, 17:14:20

Das schaut in der Tat gut aus. Allerdings warst du damals selber nicht sonderlich begeistert von dem Ergebnis: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11159113&postcount=3982

Wenn die Graka limitiert...
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11159121&postcount=3983

Kartenlehrling

2016-10-28, 17:15:04

Es sind im ja in @Ex3cut3r RotTR Test nur 10% CPU limit was angehoben wird, das resultieren in 20% mehr FPS.
Wenn man mit GPU Limitierung spielen würde wär der Vorteil wohl noch geringer.

-/\-CruNcher-/\-

2016-10-28, 20:32:23

@dargo
ich will dir dein lieblings OS ja nicht madig machen aber:
window 10 ist die privacy-pestillence jetzt auch mit eingebautem lock-in namens xbox live. (bitte jetzt keine tools nennen)
für manch einen sind die machenschaften von MS nicht mehr akzeptabel.

nach über 20 jahren mit ms produkten bin ich nicht mehr bereit diese privat einzusetzen. (beruflich ist's leider eine andere geschichte, bei mir windows + linux)

jeglichen support von vulkan kann man nur willkommen heissen.

Ja seit dem Cloud Wahn ist nichts mehr wie es einst war und unser Inder ist dort voll in seinem element, die besten Devs wurden alle zu Azure abgezogen.

Die Verschmelzung des Client ist schon weit fortgeschritten.

dargo

2016-10-29, 14:13:23

@N0Thing
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11197696&postcount=4421

d2kx

2016-11-01, 20:53:52

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

#Unite2016

Kartenlehrling

2016-11-01, 20:54:54

Leere Versprechunge ... wie alle!

Iruwen

2016-11-02, 09:24:35

"up to 30-60%", die Formulierung muss man mal wirken lassen :D

dargo

2016-11-02, 09:38:45

Leere Versprechunge ... wie alle!
Bullshit.

d2kx

2016-11-04, 02:01:22

DWLkA6-wzj0

Steam Dev Days 2016 - Vulkan Graphics

Birdman

2016-11-05, 14:08:13

Bullshit.
man beachte das "out of the Box", daher ist das ganze sehr wohl grosser Bullshit.

Hübie

2016-11-05, 16:22:15

Man beachte das "up to" (von -100% bis +30-60%) X-D Da könnten auch gewürfelte Zahlen mit Menge -undendlich bis +60 stehen und es wäre äquivalent.

aufkrawall

2016-11-05, 16:24:42

Achill

2016-11-05, 23:16:43

Die Präsentation von 2016 Vulkan DevU Seoul (https://www.khronos.org/developers/library/2016-Vulkan-DevU-Seoul) sind auch verfügbar:

- 0 Vulkan DevU Seoul 2016 Introduction.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/0-Vulkan-DevU-Seoul-2016-Introduction.pdf)
- 1 Vulkan Tutorial.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/1-Vulkan-Tutorial_English.pdf)
- 2 Vulkan Case Study.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/2-Vulkan-Case-Study.pdf)
- 3 Making SPIR V Modules.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/3-Making-SPIR-V-Modules.pdf)
- 4 Vulkan HPP.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/4-Vulkan-HPP.pdf)
- 5 Vulkan Multi Threading.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/5-Vulkan-Multi-Threading.pdf)
- 6 Pipeline Cache Object.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/6-Pipeline-Cache-Object.pdf)
- 7 Vulkan GL Performance Comparison.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/7-Vulkan-GL-Performance-Comparison.pdf)
- 8 Vulkan DevU Seoul 2016 Wrap up.pdf (https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devu-seoul/8-Vulkan-DevU-Seoul-2016-Wrap-up.pdf)

Nightspider

2016-11-05, 23:29:46

Das Multi Threading PDF ist ja auf Aztekisch. :ufinger:

Achill

2016-11-05, 23:33:19

Das Multi Threading PDF ist ja auf Aztekisch. :ufinger:

Ja, hab ich auch gesehen :D ... auf der letzten Seite wird die Quelle benannt und dort dann auf die eng. version von NV referenziert: https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/munich/mschott_vulkan_multi_threading.pdf

Hübie

2016-11-05, 23:44:44

Hey, cool. Danke für die Mühe. :up:
Man sieht wirklich dass die Anbieter mobiler Hardware großes Interesse an Vulkan haben. Ich vermisse AMD und id Software als Flaggenschwinger für den Desktop. :D

iuno

2016-11-05, 23:52:43

:ulol:
nimm die: https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/munich/mschott_vulkan_multi_threading.pdf
edit: oops, zu spaet/neue Seite nicht gesehen :redface:

@Hübie: naja das haengt vermutlich auch mit dem Standort zusammen oder? In Korea wird es schaetzungsweise mehr mobile devs geben. id und auch AMD waren ja auf Events wie etwa der GDC durchaus praesent

dargo

2016-11-06, 08:51:01

Für CPU-lastigen Mobile-Crap ist das gar nicht so unmöglich.
Auf dem PC vs DX11 natürlich sehr unwahrscheinlich. Die meisten Indie-Spiele für den PC mit Unity haben afaik auch keine sehr hohen CPU-Anforderungen.
Ein Doom hat auch keine sehr hohen CPU Anforderungen und trotzdem versägt Vulkan OpenGL um Längen im CPU-Limit. Da sind die 30-60% sogar deutlich untertrieben. Man hat da sicherlich paar Konfigurationen hingestellt und höchstwahrscheinlich mit OpenGL verglichen. Ist doch das selbe wie mit dem Marketingvideo von Microsoft und DX12. Die bis zu +50% im CPU-Limit und +20% im GPU-Limit kannst du auch nicht auf jede Konfiguration 1:1 übertragen, schon gar nicht auf jede Szene. Die Masse will was Greifbares haben und dann liefert man paar Zahlen.

Locuza

2016-11-07, 14:56:58

Wer sich vielleicht wundert, wie es um das Vulkan-Update zu Ashes steht, es gibt ein kleines Update:
## Vulkan ##

We have this most of the way completed and have test apps of it ready. The remaining issue is HLSL to Vulkan. One of our partners is working on an HLSL shader converter. Once we have that, we should be able to release a Vulkan version soon after.

Once there's a Vulkan version, we can take a look at SteamOS (Linux) support.
http://steamcommunity.com/app/228880/discussions/1/282992646966258442/

iuno

2016-11-07, 15:20:37

lol, "One of our partners" = Khronos/LunarG?!
Aber bin gespannt, was dabei raus kommt

Wie ist es eigentlich bei dx12? MS stellt schon ein frontend fuer hlsl zu dxil bereit oder?

Locuza

2016-11-07, 16:04:03

Natürlich.

Kartenlehrling

2016-11-09, 19:19:52

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

fondness

2016-11-09, 19:47:18

Graham Sellers ist im übrigen AMD-Mitarbeiter.

Loeschzwerg

2016-11-09, 19:48:45

http://phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-16.40-VLK-NV

Pfui @ AMD :(

Kartenlehrling

2016-11-09, 19:54:54

"Hier stand Mist" , hatte mich verkuckt.

Screemer

2016-11-09, 20:11:22

Wie man dem thread zum neuen amdgpu im support forum nachlesen kann, liegt das wohl am verwendeten kernel.

Loeschzwerg

2016-11-09, 20:16:07

Ok, danke für den Hinweis. Da hätte man sich den Test auch irgendwie sparen können.

SaschaW

2016-11-09, 21:36:29

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

Wo hast du bestellt? Amazon(de) sagt mir immer noch dass es keinen Termin gibt :mad:

Locuza

2016-11-09, 23:02:05

Bei Twitter: :wink:
https://twitter.com/RCalocaO/status/796105246154100736

Kartenlehrling

2016-11-10, 20:20:34

https://developer.nvidia.com/device-generated-commands-vulkan
Vulkan Device-Generated Commands

Pusht Nvidia Vulkan vielleicht wegen der Nindendo Switch (NX) so sehr?

dildo4u

2016-11-10, 20:32:59

https://developer.nvidia.com/device-generated-commands-vulkan
Vulkan Device-Generated Commands

Pusht Nvidia Vulkan vielleicht wegen der Nindendo Switch (NX) so sehr?
Nvidia pusht OpenGL schon immer und jetzt halt den Nachfolger.Gibt grad ein Linux Test in der neuen PCGH wo die 1060 die 480 zersägt.

StefanV

2016-11-10, 20:48:56

https://developer.nvidia.com/device-generated-commands-vulkan
Vulkan Device-Generated Commands

Pusht Nvidia Vulkan vielleicht wegen der Nindendo Switch (NX) so sehr?
Möglich

Aber auch weil man dort viel mehr 'Proprietären Scheiss' einbauen kann, durch die möglichen Extensions.

iuno

2016-11-10, 23:48:11

Pusht Nvidia Vulkan vielleicht wegen der Nindendo Switch (NX) so sehr?
Fuer die switch wollen sie eine eigene API eingefuehrt haben.

Nvidia pusht OpenGL schon immer und jetzt halt den Nachfolger.
Vulkan ist kein Nachfolger von OpenGL.

Natuerlich will aber NV auch Geraete auch auf anderen Plattformen verkaufen als Windows, daher ist das Engagement ganz verstaendlich.

Locuza

2016-11-10, 23:55:24

Sebastian zeigt sich auch schon begeistert:
this is the future. Fullfills my SIGGRAPH 2015 presentation wish list. Hopefully this becomes standard Vulkan & DX feature soon.
https://twitter.com/SebAaltonen/status/796783132020211713

Sollte AMD auch spätestens seit GCN Gen 3 auf Seiten der Hardware draufhaben. (Als Laie geraten)

An anderer Stelle hat Timothy von AMD einen kleinen Vulkan Eintrag auf GPUOpen geschrieben:
http://gpuopen.com/vulkan-and-doom/

Leider gibt es unter GPUOpen selten irgendetwas ausführlich, aber immerhin einige interessante Stichpunkte, wie z.B. den groben Aufbau von AMDs Treiber, wie die Zusammenarbeit grob ablief etc.

ScottManDeath

2016-11-11, 00:23:37

Möglich

Aber auch weil man dort viel mehr 'Proprietären Scheiss' einbauen kann, durch die möglichen Extensions.

Jo, das ist Sinn und Zweck des Extension Mechanismus,der sehr spezifische bzw. proprietäre HW Features Entwicklern zur Verfuegung stellt, wie z.B. http://vulkan.gpuinfo.org/listreports.php?extension=VK_AMD_gcn_shader

-/\-CruNcher-/\-

2016-11-11, 00:59:45

https://developer.nvidia.com/device-generated-commands-vulkan
Vulkan Device-Generated Commands

Pusht Nvidia Vulkan vielleicht wegen der Nindendo Switch (NX) so sehr?

Wegen Tegra Generel natürlich dort ist der Haupt nutzen ;)

DanMan

2016-11-11, 01:13:04

Jo, das ist Sinn und Zweck des Extension Mechanismus,der sehr spezifische bzw. proprietäre HW Features Entwicklern zur Verfuegung stellt, wie z.B. http://vulkan.gpuinfo.org/listreports.php?extension=VK_AMD_gcn_shader
...um sie dann später in die Spezifikation aufzunehmen, falls sie gut/beliebt sind.

Foobar2001

2016-11-11, 06:14:15

Möglich

Aber auch weil man dort viel mehr 'Proprietären Scheiss' einbauen kann, durch die möglichen Extensions.
Das ist kein "Proprietaerer Scheiss". GCN koennte das in Hardware auch. Und es geht auf den Konsolen auch schon lange.

Gipsel

2016-11-11, 13:45:08

Das ist kein "Proprietaerer Scheiss". GCN koennte das in Hardware auch. Und es geht auf den Konsolen auch schon lange.Ich glaube mich auch an ~3 Jahre alte Präsentationen zu erinnern, in denen AMD das als Feature angepriesen hat. Habe aber gerade keinen Link zur Hand.

iuno

2016-11-11, 18:07:52

Foobar2001

2016-11-11, 18:34:23

Extensions muessen spezifiziert und implementiert werden. Dauert halt.

fondness

2016-11-11, 18:55:16

Vulkan and DOOM
http://gpuopen.com/vulkan-and-doom/

iuno

2016-11-11, 19:42:39

@fondness: darauf hatte Locuza schon auf der vorigen Seite verwiesen ;)

@foobar2001: 5 Jahre? Oder gab es dahingehend etwas für DX oder ogl?

Locuza

2016-11-11, 20:13:22

Quelle/Beispiele wuerden mich auch interessieren. Wenn es mit GCN kein Probem ist und AMD schon darueber gesprochen bzw. die Funktion offenbar bei Konsolen bereitgestellt hat, sehe ich keinen Grund dafuer, dass es keine 'offizielle' Extension werden soll.
Ich frage mich nur, warum AMD nicht frueher darauf gekommen ist, so eine Extension einzureichen.
Ab welcher HW geht das denn bei NV? In dem Blogeintrag steht dazu nichts, geht es mit allen Karten, die VK koennen, also schon Kepler?
Bei der Xbox One hat Graham Wihlidal von DICE die Möglichkeit erwähnt, durch die GPU die PSOs ändern zu können:
On Xbox One, ExecuteIndirect has some incredible extensions where PSOs can be switched by indirect arguments, meaning we can issue a single ExecuteIndirect for our entire scene, regardless of state or
resource changes.
The Xbox One supports switching PSOs per multi draw packet with ExecuteIndirect! This means we can submit a single batch, regardless of PSO differences, and further reduce bottlenecks. I can’t stress how
awesome this feature is, and we will definitely be using it going forward
http://www.wihlidal.ca/Presentations/GDC_2016_Compute.pdf

Allgemein gibt es keine direkten Aussagen bezüglich der PS4, keine Ahnung, ob die PS4 die gleichen Features anbietet.
Spekulativ könnte man das Feature unterschiedlich implementieren, möglicherweise durch einen besseren Command-Processor der z.B. bei der Xbox One speziell angepasst wurde.

Als Fury X bei Hot Chips 2015 präsentiert wurde, nannte man "Dispatch Draw" als neue Fähigkeit:
https://www.techpowerup.com/forums/proxy.php?image=http%3A%2F%2Fcdn.wccftech.com%2Fwp-content%2Fuploads%2F2015%2F08%2FAMD-Radeon-R9-Nano-Fiji-GPU-Block-Diagram.jpg&hash=f13b819608518f5402b492792e4a990a
https://youtu.be/HAlbAj-iVbE?t=50m34s

Deswegen auch meine Annahme, dass spätestens ab GCN Gen 3 das auch AMD drauf haben müsste, bei älteren GPUs muss man es eventuell anders umsetzen? :confused:

Jedenfalls DICE verwendet das Feature noch nicht:
On seing frostbite boost on X1 I wonder whether you have finally used this "awesome", DX12 feaure.
no not yet, beyond experiments. but it is a cool & good feature
https://twitter.com/repi/status/790604015268749312

Die Idee bzw. das Feature wurde bei Graham Sellers von AMD schon 2015 auf der Siggraph nachgefragt:
what's kinda funny is that, I pitched the idea to @grahamsellers at SIGGRAPH 2015 and he was like "Why would you do that"? ;)
https://twitter.com/m_mschott/status/796796474696888320

Sicherlich keine Überraschung, dass AMD entsprechendes Feedback schon seit Jahren bekommt.

Foobar2001

2016-11-11, 21:57:46

@fondness: darauf hatte Locuza schon auf der vorigen Seite verwiesen ;)

@foobar2001: 5 Jahre? Oder gab es dahingehend etwas für DX oder ogl?
Die Funktionalitaet erfordert eine API wie Mantle/DX12 oder Vulkan.

Sie haetten es in Mantle einbauen koennen, aber es gab wohl andere Prioritaeten zu der Zeit.

pixeljetstream

2016-11-12, 21:19:38

Ein Shaderwechsel durch die GPU wäre in OpenGL für die NV_command_list auch technisch machbar, aber die neuen APIs machen die Umsetzung im Treiber deutlich leichter & robuster, weil die Definition des Stateobjects "kleiner" ist. In OpenGL gibt's durch diverse Extensions und die ganzen Altlasten zuviel State. Man müsste die API also erweitern um das ganze auf sinnvolle Werte zu kriegen, und dann kann man auch gleich zur neuen Technik greifen.

Als Autor des Artikels und Mitentwickler an der Technik, find ich die Nintendotheorie sehr amüsant :) da das feature wirklich nur eine weitere Evolutionsstufe ist und folgt einfach dem Trend der im Artikel erwähnt wurde.

Wenn man sich als Entwickler mit der Materie befasst, sind gewisse Wünsche zum "nächsten" Schritt zwangsläufig. Das ist kein göttlicher Geistesblitz oder so ;) Sowohl die meisten Spieleentwickler als auch unsere eigenen Forscher haben immer nen Schwung Wünsche an sehr coolen Features. Vieles davon mag technisch sogar llänger umsetzbar sein, die Hürden sind meist andere:
* ist es nicht nur machbar, sondern auch flott genug
* werden es genug leute länger benutzen damit sich die Kosten das ganze zu entwicklen und pflegen lohnt (hier helfen die neuen APIs etwas denke ich)
* Betriebssystemabstraktion der man sich unterwerfen muss (WDDM etc.) bzw. sicherheitsrelevante Vorgaben.
* sind manche Features vielleicht nur vorübergehend in der Hardware, bzw. man weiß ohnehin dass man hier was ändern will und damit wäre die API dann zukünftig nicht mehr so dolle, bzw. muss abstrakt genug sein hier etwas Spielraum zu geben. Hardware wird ja inkrementell entwickelt, manche Bausteine sind so groß die kann man nicht risikolos komplett ersetzen sondern muss iterativ rangehen.

Vieles von der Liste lässt sich ja nicht "absolut" bewerten, sondern ist in einer Grauzone...

Darum dauert beim PC manches einfach bissl länger bis es in den APIs auftaucht, da haben es Platformen mit relativen starrem OS/Hardware deutlich leichter. Wobei selbst die (wie man jetzt ja sieht) aus Kostengründen sich das Kompatibilitätsproblem auch etwas einfangen.
Und bei Konsolen isses Auftragsfertigung, sprich MS,Sony, Nintendo etc. beeinflussen diese "Grauzonen" Diskussion mit und stellen vermutlich auch Ansprüche auf ihren Anteil der Entscheidung bzw Design. Denn am Ende bezahlen sie ja für den Umfang an dem das was sie alles haben wollen. Bin daher sicher dass AMD nicht zu Sonyleuten sagen konnte, ach übrigens die von MS wollten dass wir xyz in ihren Treiber einbauen (zumindest wäre das meine Theorie dass man von dem feature nur im Zusammenhang mit der xb1 was hörte).

Foobar2001

2016-11-12, 22:24:32

Ein Shaderwechsel durch die GPU wäre in OpenGL für die NV_command_list auch technisch machbar
Gibt es nicht zig OpenGL-States die in den GPU-Programcode reinkompiliert werden heute? Wuerde wohl ziemlich schwer zu definieren sein. Dazu kommt dass die OpenGL-Pipeline-Stages gar nicht der Hardware entsprechen - zumindest bei AMD-Hardware.

Im Endeffekt wuerde man etwas haben was fast einer Vulkan Render-Pipeline entspricht.

Hübie

2016-11-13, 00:19:50

Als Autor des Artikels und Mitentwickler an der Technik, find ich die Nintendotheorie sehr amüsant :) da das feature wirklich nur eine weitere Evolutionsstufe ist und folgt einfach dem Trend der im Artikel erwähnt wurde.

Welchen Artikel meinst du? Dürfen wir hier etwa einen neues Experten-Mitglied an Board Willkommen heißen? :smile:
Deine Ausführungen klingen plausibel. Eine Änderung kann man nicht oder zumindest nur sehr schlecht hau-ruck-artig durchführen. Das sah man schon bei Intels Itanium. Den genannten Vorteil eines recht statischen Ökosystems hat ja künftig dann auch NV&Nintendo genau wie Sony/Microsoft&AMD aktuell. Daher ist es imo schon valide diese Vermutung zu äußern.

iuno

2016-11-13, 00:59:52

Den Artikel im Nvidia Blog
https://twitter.com/pixeljetstream/status/796793287302610944
Schoen dass du dich hier beteiligst :up:

pixeljetstream

2016-11-13, 13:27:19

Gibt es nicht zig OpenGL-States die in den GPU-Programcode reinkompiliert werden heute? Wuerde wohl ziemlich schwer zu definieren sein. Dazu kommt dass die OpenGL-Pipeline-Stages gar nicht der Hardware entsprechen - zumindest bei AMD-Hardware.

Im Endeffekt wuerde man etwas haben was fast einer Vulkan Render-Pipeline entspricht.

genau das meinte ich, die NV_command_list hat ja schon stateobjects wie Vulkan auch, nur sind diese "fetter", müsste man also wieder Vulkan mäßig entschlacken und dann kann man auch gleich Vulkan nehmen ;)

war nur meine Antwort auf "warum nicht in ogl", dass man in OpenGL prinzipiell per Extension alles machen kann ;) Hardware mäßig ginge das alles bei uns seit Fermi, nur war der Trend da halt noch nicht so weit. Könnte man sich ärgern und sagen, wieso erst jetzt, aber siehe Post davor ;)
Muss sich auch vor Augen halten, dass es ja nicht unbedingt sowas wie ne "master feature liste" gibt was man alles implementieren "könnte" mit der Hardware ;) Es liegt an Entwicklern Wege und Möglichkeiten zu finden, und wenn die Thematik nicht "hot" ist, dann werden sich weniger Leute die Mühe machen. Meist halt Chicken Egg Problematik.

Deswegen touren unsere Leute ja regelmäßig durch die Lande und besuchen die Spieleentwickler und tauschen sich unter NDA aus, was sinnvolle Entwicklungen wären usw. Wenn ein Chip dann nach x Jahren Planung auf den Markt kommt, muss das ja irgendwie im Markt Sinn machen. Das ist zwischen den Firmen ein Spiel mit relativen offenen Karten. Jemand wie MS oder Google weiß genau was die HW Hersteller so vorhaben, denn sie müssen ja entscheiden was in die Standards kommt. Dann wird halt Lobbyismus für diverse Features betrieben, Kompromisse erarbeitet usw.

Das ganze kann halt aus rechtlichen Gründen nicht öffentlich stattfinden, aber vieles fällt nicht so vom Himmel, dafür kostet es zu viel. Nur für den Endabnehmer erscheint es halt erst zum Zeitpunkt der Veröffentlichung als "neu". Es gibt dazu einen sehr guten Artikel von einem Entwickler bei Imagination Technologies, der die Zeiträume verdeutlicht: http://techreport.com/review/28126/semiconductors-from-idea-to-product. Als ich bei NVIDIA anfing musste ich mich daran erst gewöhnen, dass für einige Treiberleute der "aktuelle" chip, schon sehr, sehr in der Vergangenheit liegt, weil sie ja für die Chipsimulatoren die Treiber noch während der Designphase geschrieben hatten.

Darum find ich das immer lustig wenn diverse fanboys meinen die Ingenieure der Firmen würden sich untereinander hassen, oder A sei schlechter als B. Klar hat jede Firma seine Agenda für diverse Features um sich von der Konkurrenz abzusetzen, aber am Ende arbeiten die Leute auch mehr oder weniger gemeinsam an manchen Dingen. In Khronos sitzen ja auch zig Firmen die dann unter sich ausmachen müssen was Sache ist. Und viele Firmen haben sehr gute Ingenieure, manche bringen sich halt einfach mehr ein, weil sie mehr investieren können und wollen. Jemand wie NVIDIA hat einfach mehr Leute und Geld zu Verfügung in diesem Bereich, als andere Firmen. Das heißt nicht dass die einzelnen Leute und Lösungen alle automatisch "besser" sind, aber es ergibt sich deutlich mehr Spielraum. Gleichzeitig erhöht sich die Anforderung alle Märkte adequat bedienen zu müssen.

Es bleibt auf jeden Fall sehr spannend, wenn die politische Lage in den Landen nicht vor die Hunde geht, kann man sich auf ziemlich coole Sachen in der Zukunft freuen ;)

Um den ganzen noch ne Vulkanwendung zu geben, hier noch eine Präsentation die bissl anreißt wie Vulkan bei uns funktioniert:
http://on-demand.gputechconf.com/gtc/2016/presentation/s6138-christoph-kubisch-pierre-boudier-gpu-driven-rendering.pdf

Darkman.X

2016-11-13, 16:21:43

Ein echter nVidia-Angestellter? :eek:

Ich weiß nicht ob du dir mit dem "Outing" einen Gefallen getan hast. Das könnte so manchen Hater kritische Person anlocken.

Daher schon mal, bevor sie dich vergraulen: Danke für deine Texte :)

Achill

2016-11-13, 17:39:33

Ich hoffe ich falle nicht unter die Menge der Hater ... aber mir ist das eine Stufe zu weich gespült.

genau das meinte ich, die NV_command_list hat ja schon stateobjects wie Vulkan auch, nur sind diese "fetter", müsste man also wieder Vulkan mäßig entschlacken und dann kann man auch gleich Vulkan nehmen ;)

war nur meine Antwort auf "warum nicht in ogl", dass man in OpenGL prinzipiell per Extension alles machen kann ;) Hardware mäßig ginge das alles bei uns seit Fermi, nur war der Trend da halt noch nicht so weit. Könnte man sich ärgern und sagen, wieso erst jetzt, aber siehe Post davor ;)
Muss sich auch vor Augen halten, dass es ja nicht unbedingt sowas wie ne "master feature liste" gibt was man alles implementieren "könnte" mit der Hardware ;) Es liegt an Entwicklern Wege und Möglichkeiten zu finden, und wenn die Thematik nicht "hot" ist, dann werden sich weniger Leute die Mühe machen. Meist halt Chicken Egg Problematik.

Es könnte aber auch erst der Bedarf / Zugzwang durch andere Entwicklungen entstanden sein. Die Extension scheint es erst seit 04.2015 zu geben: https://www.opengl.org/registry/specs/NV/command_list.txt

Des weiteren zeigt sich beim Überfliegen von nv_command_list auch ein Problem von Extensions, diese sind zum Teil maßgeblich von weiteren Extensions abhängig und damit (m.E.) von einen anderen Hersteller nicht implementierbar bzw. nicht zu 100% korrekt implementierbar.
NV_command_list benötigt: NV_vertex_buffer_unified_memory, NV_uniform_buffer_unified_memory, NV_parameter_buffer_object, ARB_robust_buffer_access_behavior, NV_bindless_texture, ARB_bindless_texture, NV_shader_buffer_load und ARB_shader_draw_parameters

Gibt es dann für eine solche Extension (egal ob OpenGL oder Vulkan) mit diesen Rattenschwanz von Abhängigkeiten ein Set an Conformitäts-Test, sodass eine entsprechend hohe Testabdeckung gegeben ist und somit ein realistischer Weg für einen anderen IHVs für eine eigene Implementierung besteht?

Deswegen touren unsere Leute ja regelmäßig durch die Lande und besuchen die Spieleentwickler und tauschen sich unter NDA aus, was sinnvolle Entwicklungen wären usw. Wenn ein Chip dann nach x Jahren Planung auf den Markt kommt, muss das ja irgendwie im Markt Sinn machen. Das ist zwischen den Firmen ein Spiel mit relativen offenen Karten. Jemand wie MS oder Google weiß genau was die HW Hersteller so vorhaben, denn sie müssen ja entscheiden was in die Standards kommt. Dann wird halt Lobbyismus für diverse Features betrieben, Kompromisse erarbeitet usw.

Das Problem an NDAs ist, dass man nicht weiß welche Nebenabsprachen getroffen werden. So ist immer irgendwie die Tür offen für Wenn-Dann-Zwänge - sprich: Du bekommst Feature XY, dafür musst du aber auch Bibliothek Z von uns nutzen.

Das ganze kann halt aus rechtlichen Gründen nicht öffentlich stattfinden, aber vieles fällt nicht so vom Himmel, dafür kostet es zu viel.
[..]

Ich glaube nicht das es "rechtlichen Gründen" sind sondern es passiert aus wirtschaftlichen Gründen, um ein Vorsprung gegenüber der Konkurrenz zu haben / dies zu gewährleisten - wir haben immerhin Kapitalisum / gewinnorientiertes Wirtschaften.

--
BTW: Welcome to 3DC!

pixeljetstream

2016-11-13, 21:41:16

@Achill
Wie Du sagst ist es erforderlich wirtschaftlich zu arbeiten, sorry falls da meine Formulierung rund um die NDAs zu harmlos klang, in jedem Fall trifft sie ja alle Firmen gleich.
Meiner Meinung nach sind die Hardwarehersteller den Contentprovidern relativ ausgeliefert. Aber das ist ne Glaubenssache, weswegen hier jeder Firmen für das was hinter den NDAs läuft beschuldigen oder verteidigen kann wie er will.

Ich denke aber schon, dass es hier keine Technik zum Selbstzweck ist oder man den Entwicklern was vormachen kann, sondern eben echte Probleme in deren Anwendungen addressiert. Viele der Hardwareleute als auch der Softwareentwickler (game engines, dcc usw.) haben sich das Thema Grafik aus Überzeugung ausgesucht. Und es gibt ja immer noch viel Veröffentlichungen und Diskussionen bei GDC, SIGGRAPH, HPG... trotz NDAs. auch wenn das nach Weichspühler hoch zwei klingt.

Du hast Recht ne vendor extension kann man nicht immer einfach übernehmen. Besteht Interesse von anderen Herstellern, so einigt man sich dann im Rahmen von EXT bzw. Idealfall ARB/KHR Extensions auf einen Kompromiss. Manchmal isses aber auch trivial und man übernimmt sie direkt. Sollte es Unklarheiten geben fragt man einfach nach. Die Treiberentwickler der verschiedenen Firmen stehen ja eh in Kontakt durch die Zusammenarbeit an den Standards.

Die GL Extension war die nächste Evolutionsstufe auf NV_bindless_multi_draw_indirect, welche ARB/AMD_multi_draw_indirect als Vorläufer hatte. Sinn und Zweck war das GPU occlusion culling zu verbessern. Das ganze wurde auch jedes Jahr öffentlich präsentiert.

2013 ARB_multi_draw_indirect
http://on-demand.gputechconf.com/gtc/2013/presentations/S3032-Advanced-Scenegraph-Rendering-Pipeline.pdf
2014 NV_bindless_multi_draw_indirect
http://on-demand.gputechconf.com/siggraph/2014/presentation/SG4117-OpenGL-Scene-Rendering-Techniques.pdf
2015 NV_command_list
http://on-demand.gputechconf.com/gtc/2015/presentation/S5135-Christoph-Kubisch-Pierre-Boudier.pdf

Die bindless multi draw indirect Lösung war nicht so optimal, hätte man sich sparen können und gleich den NV_command_list Weg einschlagen sollen. Aber so ist halt die Entwicklung mal macht man was gutes, mal nicht so dolle.

Das Argument des Zugzwangs kann ich daher in diesem Fall nicht nachvollziehen, da es von anderen Herstellern unter OpenGL keine vergleichbaren Entwicklungen gab. Der Grund warum und für wen wir das machten, ist denke ich aus den Folien ersichtlich. Oder ich hab Dich da komplett falsch verstanden.

sakul

2016-11-13, 23:43:52

Fuer die switch wollen sie eine eigene API eingefuehrt haben.

Vulkan ist kein Nachfolger von OpenGL.

Natuerlich will aber NV auch Geraete auch auf anderen Plattformen verkaufen als Windows, daher ist das Engagement ganz verstaendlich.

Vor allem will NV nicht mit leeren Händen dastehen sollte DX12 scheitern was nicht mal sooooo unwahrscheinlich sein könnte, da es ja nur von einer Plattform unterstützt wird. So könnte das Umsteige Kriterium Nr.1 für Windows 10 DX12 sich als Bumerang erweisen wenn die Verbreitung zu gering ausfällt in der Zukunft. Mir ein Grund für die aggressive Upgrade Politik seitens Microsoft.

Entropy

2016-11-18, 00:24:22

Ab welcher HW geht das denn bei NV? In dem Blogeintrag steht dazu nichts, geht es mit allen Karten, die VK koennen, also schon Kepler?
Von der Hardware her kann man das schon lange mit der GPU, das ist nichts anderes als Daten in einen Speicherbereich zu schreiben der auch vom Commandprozessor 'gesehen' wird. Es wurde selten mal auf der XBox360 und PS3 verwendet. Das einzige technische 'Problem' war es, es cache-Kohärent zu implementieren, weil die einzelnen GPU-Teile unabhängig laufen.

Jedoch wurde eigentlich in die Gegenrichtung optimiert, weil die GPUs sowieso am Limit liefen. Siehe z.B. die Sony Edge library.

Ich finde es deswegen verwunderlich was diese Extension soll.

pixeljetstream

2016-11-20, 12:31:10

Man kann ohne readbacks/CPU synchronisation, den command-buffer beeinflussen. Auf die ART kann man z.b latenzfrei exakteres occlusion culling implementieren, oder wie im Artikel auch erwähnt, Arbeitspakete nach verschiedenen shadern klassifizieren usw.

Man verschwendet auf die Art weniger Arbeit, weil man entweder Dinge erst gar nicht berechnet die nicht wichtig gewesen wären, oder weil man leichter spezialisierte Shader verwenden kann. Vor- und Nachteile werden ja im Artikel genannt. Dass es das Feature nun für PC gibt, ist in der Entwicklerszene sehr gut aufgenommen worden.

SaschaW

2016-12-07, 20:43:28

Meine Kopie vom Vulkan Programming Guide ist heute endlich angekommen:

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

Dacht schon dass wird dieses Jahr nix mehr als bei Amazon letzte Woche was von "Liefertermin zwischen 17. Dezember und 22. Februar stand" :freak:

aufkrawall

2016-12-07, 20:49:03

Brauchst du das denn überhaupt, oder ist das für die Vitrine? :D

Hübie

2016-12-07, 20:55:05

Er programmiert doch bereits Vulkan-Demos. ;)

N0Thing

2016-12-07, 22:38:20

Eben. ;)

Foobar2001

2016-12-07, 22:41:18

Brauchst du das denn überhaupt, oder ist das für die Vitrine? :D
Ich finde es ist eher fuer die Vitrine. Inhalt ist nicht wirklich mehr als die spec PDF, aber ist ne gute Referenz.

Kartenlehrling

2016-12-07, 22:55:13

Ich habe ja gehofft das Vulkan beim Mobil richtig durchstarte,
aber wenn man sich die Bewertunge anschaut, läuft das nicht wirklich gut.
Ich habe leider ein galaxy 6edge das bekommt vielleicht erst im Januar sein Android7.0+Vulkan.

https://play.google.com/store/apps/details?id=com.superevilmegacorp.game.vulkan&hl=de
VG: Vulkan Beta

Foobar2001

2016-12-07, 23:28:04

Das sind die ganzen Trottel, die ueberhaupt keinen Vulkan-Support haben in ihrem Telefon.

SaschaW

2016-12-08, 08:23:35

Brauchst du das denn überhaupt, oder ist das für die Vitrine? :D

Eher für die Vitrinie. Manchmal ist es aber auch ganz schick wenn man in so einer Guide nachschlagen kann statt sich online durch die Specs zu wälzen.

Ist halt eher ein Buch für die die vorher eine andere API genutzt haben und jetzt mit Vulkan loslegen wollen. Wer schon etwas intensiver mit Vulkan entwickelt wird aus dem Buch nichts wirklich Neues lernen.

d2kx

2016-12-12, 22:21:36

OpenVR/SteamVR 1.0.5 mit Vulkan Support (https://github.com/ValveSoftware/openvr/releases)
GitHub Releases

Vulkan support in SteamVR (https://github.com/ValveSoftware/openvr/wiki/Vulkan)
GitHub Wiki

The Talos Principle - Update 277544 (http://steamcommunity.com/app/257510/discussions/0/1843493219426004671/)
New features:
- Added support for latest AMD and nVidia cards.

Improvements:
- Improved stability and performance on Vulkan API.

Bug fixes:
- Fixed issues with fullscreen rendering on Vulkan on Linux.
- Fixed a rare crash when exiting the game.

Kartenlehrling

2016-12-13, 20:18:12

http://schedule.gdconf.com/speaker/chajdas-matthaeus.37653
D3D12 & Vulkan: Lessons Learned

Hatte er nicht schon dieses Jahr einen Vortrag gehabt, war furchbar langweilig :)

Pirx

2016-12-16, 12:19:29

Die neueste Version von The Division bzw. Unity 5.6 Beta unterstützt nun auch Vulkan (?)

https://blogs.unity3d.com/2016/12/13/unity-5-6-beta-is-now-available/

d2kx

2016-12-19, 22:34:52

Nintendo's Switch Game Console Is Vulkan & OpenGL Conformant (http://phoronix.com/scan.php?page=news_item&px=Nintendo-Switch-Vulkan-Conform)
Phoronix

Unicous

2016-12-19, 22:39:50

Nintendo's Switch Game Console Is Vulkan & OpenGL Conformant (http://phoronix.com/scan.php?page=news_item&px=Nintendo-Switch-Vulkan-Conform)
Phoronix

Ich hatte ja schon die stille Vermutung, dass Nvidias krasse neue API mindestens auf Vulkan aufbauen wird, vllt. ist es auch nichts anderes als Vulkan.:freak:

DanMan

2016-12-20, 00:22:21

Damit sollte das Ding ja aus dem Tegra so viel herausbekommen wie möglich. Nett.

Hübie

2016-12-20, 00:37:31

Ich hatte ja schon die stille Vermutung, dass Nvidias krasse neue API mindestens auf Vulkan aufbauen wird, vllt. ist es auch nichts anderes als Vulkan.:freak:

Na ja. Zumindest ergeben jetzt die ganzen Anstrengungen der vergangenen 13-15 Monate in puncto Vulkan von nVidia einen Sinn. ;)

Godmode

2016-12-20, 00:39:22

Na ja. Zumindest ergeben jetzt die ganzen Anstrengungen der vergangenen 13-15 Monate in puncto Vulkan von nVidia einen Sinn. ;)

Schön wäre es ja, wenn es endlich wieder eine einheitliche 3D-API für Spiele geben würde. Und Vulkan würde ich den Vorzug geben, alleine schon weil es auch auf anderen Plattformen als Windows läuft.

=Floi=

2016-12-20, 00:50:50

mit vulkan haben wir ja im grunde diese api und trotzdem nimmt sie keiner her.

wäre ja auch genial, wenn größere und mehrere open source projekte vulkan nützen würden. so ist es komplett in einer nische.
wobei eigentlich nur moderne AAA titel von der cpu entlastung profitieren würden.

Unicous

2016-12-20, 00:58:18

Es wäre aber auch sehr verlogen, wenn sie das hier behaupten
NVIDIA additionally created new gaming APIs to fully harness this performance. The newest API, NVN, was built specifically to bring lightweight, fast gaming to the masses. und es am Ende wirklich nur Vulkan wäre, mit nur leichten Anpassungen für Hardware und OS.

Und den wirklichen Vorteil (für den Endkunden) sehe ich auch nicht. Ein geschlossenes Ökosystem bietet IMHO keine Vorteil wenb es auf einer offenen API basiert. Wenn dann gibt es Portierungen auf Switch und nicht andersherum, denn diese Spiele/IPs dürften Nintendo/Switch-exklusiv bleiben... außer Nintendo würde von seiner Firmenpolitik abweichen und das kann ich mir bis auf die Go-Ableger die eigentlich nur Appetizer für die echten Spiele sind, nicht vorstellen.