DirectX 12 Grafik-API

[Snafu]

JustCause3 (Nvidia) 01.12.2015 und Hitman (AMD) 08.12.2015 werden wohl die ersten DX12 Games sein.
RotTR wird ja leider erst XBone exklusiv sein.

Fable Legends könnte noch im Oktober kommen und Gears of War Ultimate Edition kommt vielleicht auch noch vor Dezember.
Bis zum Hitman release hat man dann hoffentlich 4 DirectX12 Spiele mit denen man die Lage etwas einschätzen kann. Die riesen Disskussion um eine Beta versteh ich auch nicht

[Hübie]

Die Masse an Gewusel gibt keinen Aufschluss darüber, wie viel und für was Compute genutzt wird.
Sieht eher nach recht harmlosem PP aus, aber das kann natürlich auch täuschen.

Das Glare muss aber auf alle Modelle appliziert werden, also ist das schon wichtig.
@fondness: Ich spiele das nicht herunter sondern betrachte es erst einmal nur skeptisch und hinterfrage Dinge die wir nicht prüfen können. Und DOCH, es geht um Ashes of Singularity, da dies der einzige Titel ist von dem Entwickler sich zu Wort meldeten. Von allen anderen großen Schmieden hört man gar nichts in dieser Hinsicht. Also darf ich doch auch mal Skepsis anbringen.

[Loeschzwerg]

@Hübie: Bist du jetzt schlauer durch die Screens?

[Hübie]

Nein eigentlich nicht, aber zumindest ein Vergleich mehr, der zeigt, dass der Test suboptimal ist. Aber das Verhalten bei dir ist etwas anders wie man sieht.
Die CPU arbeitet aber auch in deinem Fall fleißig mit und spiked herum. Die GPU ist dagegen konstanter ausgelastet.

[Kartenlehrling]

Die chance das es noch eine nachträgliche DX12 Version von "Thief" gibt ist wohl genauso gross wie das es keine von Battlefield4 gibt.
Ich habe mal einen Benchmarkdruchlauf von Thief gemacht und dachte schon es wär was kaputt,
auf jedenfall war die DX11@win8.1 Version ca.2-5fps schneller als die Mantle Version auf meiner HD7970.

Aber wirklich besser war es wohl vor einem Jahr auch nicht.

http://www.computerbase.de/2014-03/amd-mantle-thief-benchmarks/2/#diagramm-thief-2560-1600-fxaa-16xaf
Thief – 2.560 × 1.600 FXAA/16xAF Mantle vs. DirectX

[Tamagothi]

In 1600p bist du vermutlich im GPU Limit. Async Compute soll ja nicht immer was bringen. Teils sogar schlecht sein ( bei zu viel )

In Thief wurde es ja benutzt aber wer sagt den das die Max FPS steigen müssen? Könnte es nicht sein das die min FPS steigen was wichtiger ist als max FPS?

Bei dem test sieht man es leider nicht.

[aufkrawall]

Ist schwer zu überprüfen, ob Thief es wirklich genutzt hat.
Nur weils auf einer Folie steht, muss es nicht automatisch stimmen.

[aufkrawall]

Beginning with driver release R358, Fermi GPUs will use WDDM 2.0
http://us.download.nvidia.com/Windows/Quadro_Certified/355.85/355.85-win10-quadro-grid-release-notes.pdf

[Kickstart]

Weiss hier Jemand ob und wann sich Leonidas im News-Bereich sich zu dem Problem der Async Shaders & Nvidia-Karten äußern möchte?

[aufkrawall]

Das weiß nur er selbst. Wo nun Heise etc. drüber geschrieben haben, wirds langsam aber wirklich mal Zeit.

[Kickstart]

Auf meine direkte Frage an ihn hab ich bisher leider keine Antwort. -> https://www.forum-3dcenter.org/vbulletin/showthread.php?t=566447

[Godmode]

Wenn ich es richtig verstanden habe, dann ist einer der größten Unterschiede von D3D11 zu D3D12, dass unter D3D12 der Entwickler viel mehr Kontrolle über die Hardware bekommt. Das zeigt sich dann darin, der er sich selber um Synchronisation, Memory Management, etc. kümmern muss. Unter D3D11 hatte der Dev da weniger Einfluss und die Synchronisation, Memory Management wurden vom Treiber gemacht, der dann natürlich auch Optimierungen vornehmen konnte.

Wenn jetzt unter D3D12 aber der Entwickler die Synchronisation, etc. machen muss und der Treiber weniger stark eingreifen kann, würde das erklären warum plötzlich Latenzen auftauchen, wenn die Compute- und Graphics-Queue gleichzeitig mit Command Lists gefüttert werden.

Wenn Nvidia keine extra Hardware wie die ACEs von GCN hat, könnte die Verteilung und Synchronisation der Commands bei D3D11 in der Treiberebene optimiert worden sein. Da unter D3D12 aber die Hardware auf einem deutlich niedrigerem Level angesprochen wird, dürfen sie nicht mehr einfach auf Treiberebene optimieren, den wozu legt der Entwickler seine Fences, Barriers, whatever fest, wenn der Treiber dann wieder alles anders umschichtet.

[Gipsel]

Wenn Nvidia keine extra Hardware wie die ACEs von GCN hat, könnte die Verteilung und Synchronisation der Commands bei D3D11 in der Treiberebene optimiert worden sein. Da unter D3D12 aber die Hardware auf einem deutlich niedrigerem Level angesprochen wird, dürfen sie nicht mehr einfach auf Treiberebene optimieren, den wozu legt der Entwickler seine Fences, Barriers, whatever fest, wenn der Treiber dann wieder alles anders umschichtet.Nun, Umordnen verschiedener Kernel-Calls (bzw. eher opportunistisches Scheduling mit der Möglichkeit der OoO-Abarbeitung) machen die ACEs ja gerade, das ist also mitnichten verboten (das ist ja mit ein Punkt, der mit asynchronen Shadern ermöglicht wird). Die GPU (oder der Treiber) muß nur sicherstellen, daß die definierten Synchronisationspunkte (also die erwähnten Fences bzw. Barriers) eingehalten werden. Bei GCN ist es eben kein Problem, daß auf der GPU (und sogar auf jeder CU) simultan verschiedene Shader verschiedener Typen (also Vertex, Pixel, Compute, whatever) aus verschiedenen Kontexten laufen, in beliebiger Mixtur mit (im Prinzip) vom Entwickler definierten Prioritäten. NV-GPUs scheinen damit eher ein Problem zu haben.
In dem von aufkrawall erwähnten Artikel von Heise (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html) haben die eine nV-Präsentation zu VR von der diesjährigen GDC ausgegraben, in denen nV klar gesagt hat, daß sie Kontext-Switches nur an Drawcall-Grenzen durchführen können und sich dies erst in nicht allzu naher Zukunft ändern wird. Zu jeder Zeit können also auf nV-GPUs offenbar immer nur Shader aus einem einzigen Kontext ausgeführt werden, wenn ich das richtig interpretiere.

http://abload.de/img/nv_preemption1xmypu.jpg http://abload.de/img/nv_preemption2p4ain.jpg

[fondness]

Ich bin nach wie vor gespannt wie nVidia dazu Stellung bezieht.

Erwartest du wirklich, dass da noch was kommt? Dutzende Seiten haben bei NV zu dem Thema angefragt und unisono keine Antwort erhalten. Zumal der Sachverhalt recht eindeutig ist, siehe auch den Beitrag von Gipsel über mir. Hier immer noch Asehes of the Singulaity die Schuld zu geben macht wenig Sinn.

[][immy]

Nun, Umordnen verschiedener Kernel-Calls (bzw. eher opportunistisches Scheduling mit der Möglichkeit der OoO-Abarbeitung) machen die ACEs ja gerade, das ist also mitnichten verboten (das ist ja mit ein Punkt, der mit asynchronen Shadern ermöglicht wird). Die GPU (oder der Treiber) muß nur sicherstellen, daß die definierten Synchronisationspunkte (also die erwähnten Fences bzw. Barriers) eingehalten werden. Bei GCN ist es eben kein Problem, daß auf der GPU (und sogar auf jeder CU) simultan verschiedene Shader verschiedener Typen (also Vertex, Pixel, Compute, whatever) aus verschiedenen Kontexten laufen, in beliebiger Mixtur mit (im Prinzip) vom Entwickler definierten Prioritäten. NV-GPUs scheinen damit eher ein Problem zu haben.
In dem von aufkrawall erwähnten Artikel von Heise (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html) haben die eine nV-Präsentation zu VR von der diesjährigen GDC ausgegraben, in denen nV klar gesagt hat, daß sie Kontext-Switches nur an Drawcall-Grenzen durchführen können und sich dies erst in nicht allzu naher Zukunft ändern wird. Zu jeder Zeit können also auf nV-GPUs offenbar immer nur Shader aus einem einzigen Kontext ausgeführt werden, wenn ich das richtig interpretiere.

http://abload.de/img/nv_preemption1xmypu.jpg http://abload.de/img/nv_preemption2p4ain.jpg
Klingt so als wenn es bei nvidia also wirklich nur als "Checklisten"-Feature angeboten wird, man aber nicht erwarte das es wirklich genutzt wird.
Was natürlich auch realistisch ist. Bis das erste DX12 Spiel wirklich kommt wird noch einiges an Zeit verstreichen (Fable mal nicht mitgerechnet). Konsolen-Ports werden sich eher auf DX11 wegen Win8 Support stützen. Bis dahin ist auch neue Hardware raus die das dann effizienter lösen kann.

[dargo]

[immy;10766085'] Konsolen-Ports werden sich eher auf DX11 wegen Win8 Support stützen.
Ähm was? Du hast schon mitbekommen, dass DX12 auch auf der XBox One verwendet wird? Hier hast du eine kleine Liste was DX12 Games angeht, zumindest was bisher bekannt ist.
http://www.pcgameshardware.de/DirectX-12-Software-255525/Specials/Games-Liste-Uebersicht-Ark-DayZ-Star-Citizen-1164994/

[Godmode]

Nun, Umordnen verschiedener Kernel-Calls (bzw. eher opportunistisches Scheduling mit der Möglichkeit der OoO-Abarbeitung) machen die ACEs ja gerade, das ist also mitnichten verboten (das ist ja mit ein Punkt, der mit asynchronen Shadern ermöglicht wird). Die GPU (oder der Treiber) muß nur sicherstellen, daß die definierten Synchronisationspunkte (also die erwähnten Fences bzw. Barriers) eingehalten werden. Bei GCN ist es eben kein Problem, daß auf der GPU (und sogar auf jeder CU) simultan verschiedene Shader verschiedener Typen (also Vertex, Pixel, Compute, whatever) aus verschiedenen Kontexten laufen, in beliebiger Mixtur mit (im Prinzip) vom Entwickler definierten Prioritäten. NV-GPUs scheinen damit eher ein Problem zu haben.
In dem von aufkrawall erwähnten Artikel von Heise (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html) haben die eine nV-Präsentation zu VR von der diesjährigen GDC ausgegraben, in denen nV klar gesagt hat, daß sie Kontext-Switches nur an Drawcall-Grenzen durchführen können und sich dies erst in nicht allzu naher Zukunft ändern wird. Zu jeder Zeit können also auf nV-GPUs offenbar immer nur Shader aus einem einzigen Kontext ausgeführt werden, wenn ich das richtig interpretiere.

http://abload.de/img/nv_preemption1xmypu.jpg http://abload.de/img/nv_preemption2p4ain.jpg

Die Präsentation habe ich mir damals sogar im Detail ansehen, aber schon wieder vergessen.

Was für Gründe außer viel einfachere Sheduler gäbe es sonst noch? Man hat jetzt im Falle eines GM200 zb. 24 SMMs und jeder SMM hat wiederum 4 Blöcke von ALUs wo jeder Block wiederum einen eigen Warp Sheduler hat. (ka ob es in Hardware auch so abgebildet ist) Insgesamt hat man also 24*4 Blöcke von je 32 ALUs was 96 Blöcken entspricht. Wenn das gut gemacht wäre, könnte jetzt jeder einzelne Block von den 96 in unterschiedlichen Kontexten arbeiten. Man hätte damit eine sehr feine Granularität. Wenn verschiedene Kontexte nur auf GPC Ebene möglich sind, wären es gar nur mehr 6 Blöcke im Falle eines GM200 und die Auslastung würde wohl schon deutlich sinken. Wenn das aber selbst auf GPC Ebene nicht funktioniert, dann wäre das schon eine schwache Vorstellung gegenüber GCN. Andererseits würde es mich aber auch nicht wundern, wenn man sich die Auslegung der GM20x Chips ansieht.

[][immy]

Ähm was? Du hast schon mitbekommen, dass DX12 auch auf der XBox One verwendet wird? Hier hast du eine kleine Liste was DX12 Games angeht, zumindest was bisher bekannt ist.
http://www.pcgameshardware.de/DirectX-12-Software-255525/Specials/Games-Liste-Uebersicht-Ark-DayZ-Star-Citizen-1164994/
ja und?
Was hat die xbone damit zu tun? Ports für den PC werden erst mal noch eine ganze weile auch Windows 8 unterstützen. Also wirst du davon ausgehen können, das es DX11 Ports werden, also ohne async. Das wo dann DX11 & DX12 kommt wird dann wohl "nur" die Drawcall-Optimierungen nutzen. Damit hat nvidia ja auch keine Probleme. Aber Async compute werden wir wohl erst mal nicht sehen.

für nvidia sehe ich da aber die nächsten 1-2 Jahre keine Probleme. Und bis dahin sind eh neue Karten raus.

edit:
eventuell hast du mein "Konsole Ports" nur missverstanden. Ich meinte Ports von Konsole zum PC nicht anders herum.

[aufkrawall]

Win 10 könnte dieses Jahr noch Win 7 auf Steam überholen, das würd ich nicht unterschätzen.

[Novum]

Nun, Umordnen verschiedener Kernel-Calls (bzw. eher opportunistisches Scheduling mit der Möglichkeit der OoO-Abarbeitung) machen die ACEs ja gerade, das ist also mitnichten verboten (das ist ja mit ein Punkt, der mit asynchronen Shadern ermöglicht wird). Die GPU (oder der Treiber) muß nur sicherstellen, daß die definierten Synchronisationspunkte (also die erwähnten Fences bzw. Barriers) eingehalten werden. Bei GCN ist es eben kein Problem, daß auf der GPU (und sogar auf jeder CU) simultan verschiedene Shader verschiedener Typen (also Vertex, Pixel, Compute, whatever) aus verschiedenen Kontexten laufen, in beliebiger Mixtur mit (im Prinzip) vom Entwickler definierten Prioritäten. NV-GPUs scheinen damit eher ein Problem zu haben.
In dem von aufkrawall erwähnten Artikel von Heise (http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html) haben die eine nV-Präsentation zu VR von der diesjährigen GDC ausgegraben, in denen nV klar gesagt hat, daß sie Kontext-Switches nur an Drawcall-Grenzen durchführen können und sich dies erst in nicht allzu naher Zukunft ändern wird. Zu jeder Zeit können also auf nV-GPUs offenbar immer nur Shader aus einem einzigen Kontext ausgeführt werden, wenn ich das richtig interpretiere.

http://abload.de/img/nv_preemption1xmypu.jpg http://abload.de/img/nv_preemption2p4ain.jpg
Async Compute und Preepmtion sind zwei voellig getrennte Probleme. Du kannst GPUs haben die Async unterstuetzen und trotzdem nicht in der Lage sind einen Workload zu unterbrechen waehrend er laeuft. Und ich bin mir auch relativ sicher, dass das bei zumindest frueheren GCN-GPUs so ist.

[dargo]

[immy;10766236']ja und?
Was hat die xbone damit zu tun?
Ganz einfach... noch weniger Portierungsaufwand dank gleicher API.

[immy;10766236']Ports für den PC werden erst mal noch eine ganze weile auch Windows 8 unterstützen. Also wirst du davon ausgehen können, das es DX11 Ports werden, also ohne async.
Das neue Tomb Raider wird ASC nutzen.
http://www.pcgameshardware.de/Rise-of-the-Tomb-Raider-Spiel-54451/News/Technisch-wieder-ganz-vorne-dabei-1168378/

Und keine Ahnung was das Argument mit deinem Windows 8 soll. Ist ja nicht so, dass Windows 10 kein DX11 unterstützt.

[deekey777]

Ganz einfach... noch weniger Portierungsaufwand dank gleicher API.
Schließlich sind es ja ganz gewöhnliche APUs, die auch frei zu kaufen sind.

[immy;10766085']Klingt so als wenn es bei nvidia also wirklich nur als "Checklisten"-Feature angeboten wird, man aber nicht erwarte das es wirklich genutzt wird.
Was natürlich auch realistisch ist. Bis das erste DX12 Spiel wirklich kommt wird noch einiges an Zeit verstreichen (Fable mal nicht mitgerechnet). Konsolen-Ports werden sich eher auf DX11 wegen Win8 Support stützen. Bis dahin ist auch neue Hardware raus die das dann effizienter lösen kann.
Es klingt eher, dass nvidia mit Fermi ein Design entwickelt hat, das bis heute gemolken werden kann.

[][immy]

Und keine Ahnung was das Argument mit deinem Windows 8 soll. Ist ja nicht so, dass Windows 10 kein DX11 unterstützt.
also entweder wir schreiben aneinander vorbei oder ... keine Ahnung

Also es wir kein Spiel in nächster Zeit (außer vielleicht von MS) exklusiv auf DX12 setzen. Alles wird noch DX11 bleiben um auch weiterhin potentielle Kunden die Windows 7/8 einsetzen nicht zu verschrecken. D.h. nvidia hat hier überhaupt keine Probleme, das ein DX12 Feature nicht performat läuft, weil es einfach nicht genutzt wird. Auf mehr will ich gar nicht hinaus.

Das mit der "gleichen" API bei er xbone ist auch quatsch. Sie ist zwar sehr ähnlich, hier wird aber dank der Architektur (esram, HSA & co) viel mehr optimiert werden, damit etwas läuft. 1:1 wird man es nicht rüberziehen können. Ja PC => xbone würde vielleicht noch klappen (wenn man die Performance außer acht lässt), aber umgekehrt eben nicht. Ja der Aufwand wird durch DX12 geringer, aber dafür müssen die Spiele-Entwickler erst mal auf DX12 setzen (und nicht nur optional).
Die meisten werden sicherlich noch auf DX11 Pfade setzen um einen möglichst großen Kundenkreis anzusprechen. Und es spricht eigentlich auch nix dagegen wenn async-aufgaben "serialisiert" werden wie es wohl derzeit bei nvidia Karten läuft. Ist zwar nicht so flott, aber an Performance mangelt es am PC für gewöhnlich nicht, wenn man sich die High-End-Karten vornimmt (was aber aus Entwicklersich auch unwahrscheinlich ist).

So um wieder zu meiner Kernaussage zu kommen, nvidia hat keine Problem in nächster Zukunft, wenn sich tatsächlich herausstellt das es sich nicht nur um ein Treiberproblem handelt sondern das die Hardware nicht anders kann.

[dargo]

[immy;10766442']also entweder wir schreiben aneinander vorbei oder ... keine Ahnung

Also es wir kein Spiel in nächster Zeit (außer vielleicht von MS) exklusiv auf DX12 setzen. Alles wird noch DX11 bleiben um auch weiterhin potentielle Kunden die Windows 7/8 einsetzen nicht zu verschrecken. D.h. nvidia hat hier überhaupt keine Probleme, das ein DX12 Feature nicht performat läuft, weil es einfach nicht genutzt wird. Auf mehr will ich gar nicht hinaus.

Und was hindert den Entwickler daran zwei Renderpfade (DX11 und DX12) zu intergrieren? Das war auch eine ganz selbstverständliche Sache beim Übergang von DX9 auf DX10/11.

[immy;10766442']
Das mit der "gleichen" API bei er xbone ist auch quatsch. Sie ist zwar sehr ähnlich, hier wird aber dank der Architektur (esram, HSA & co) viel mehr optimiert werden, damit etwas läuft

Was willst du mit HSA bei einer Konsole mit zwei Speicherpools?

[immy;10766442']
Die meisten werden sicherlich noch auf DX11 Pfade setzen um einen möglichst großen Kundenkreis anzusprechen. Und es spricht eigentlich auch nix dagegen wenn async-aufgaben "serialisiert" werden wie es wohl derzeit bei nvidia Karten läuft. Ist zwar nicht so flott, aber an Performance mangelt es am PC für gewöhnlich nicht, wenn man sich die High-End-Karten vornimmt (was aber aus Entwicklersich auch unwahrscheinlich ist).

Verzeihung... ich habe vergessen, dass der PC-Markt nur aus GTX980Tis/Titan X und Furys besteht.

[Schnoesel]

So um wieder zu meiner Kernaussage zu kommen, nvidia hat keine Problem in nächster Zukunft, wenn sich tatsächlich herausstellt das es sich nicht nur um ein Treiberproblem handelt sondern das die Hardware nicht anders kann.

Das ist richtig sie haben kein Problem, aber eben auch keinen Vorteil den Async Shader bieten könnten. Vom Performanceaspekt wird das letztlich nur über die Zeit zu beantworten zu sein.

[DinosaurusRex]

[immy;10766442']
Also es wir kein Spiel in nächster Zeit (außer vielleicht von MS) exklusiv auf DX12 setzen. Alles wird noch DX11 bleiben um auch weiterhin potentielle Kunden die Windows 7/8 einsetzen nicht zu verschrecken. D.h. nvidia hat hier überhaupt keine Probleme, das ein DX12 Feature nicht performat läuft, weil es einfach nicht genutzt wird.

Hat Battlefront nicht minimum DX12? DICE ist seit Jahren eine Autorität wenn es um Videospielgrafik geht und sollte Nvidia da schlecht abschneiden, werden die den Image-Verlust nicht mal eben so weg stecken können. Von der potenziellen Türöffnerwirkung mal ganz zu schweigen: Sollte DICE ein reines DX12-Spiel finanziell erfolgreich stemmen können, werden andere Devs sicher folgen. Die Synergien mit den umsatzstarken Konsolen sind ja ohnehin vorhanden.

[aufkrawall]

Hat Battlefront nicht minimum DX12?
Wie stellst du dir das denn vor? :redface:

Mit etwas Glück gibts ein Jahr später DX12 Exclusives (abseits von Fable), Andersson hofft auf diesen Zeitraum. Vorher ist das aber eher unwahrscheinlich.

[fondness]

Es braucht allerdings auch nichts DX12 exklusives um Dinge wie Async Shaders einzusetzen.

[aufkrawall]

Einige scheinen hier nicht mitbekommen zu haben, dass es auch für Tomb Raider schon angekündigt ist (obwohl ichs schon mehrfach erwähnt hab...).

[StefanV]

Und was hindert den Entwickler daran zwei Renderpfade (DX11 und DX12) zu intergrieren? Das war auch eine ganz selbstverständliche Sache beim Übergang von DX9 auf DX10/11.
Da vergisst du aber eine Kleinigkeit ;)
a) brauchte man für DX10/11 ein Windows Vista, was aber eher unbeliebt war.
Erst als Windows 7 verbreitet war und XP kaum mehr genutzt, konnte man den Renderpfad weglassen...

b) Gibt es für alle Windows 7 und 8(.1) Nutzer ein kostenloses Upgrade auf Windows 10.
Und jetzt schauen wir mal, wie weit DX11 GPUs verbreitet sind, @Steam:
~80%
Davon jetzt die Radeon HD 5k und 6k Serie abgezogen:
~75%
Die Frage ist nur, wie es mit Intel HD 4k, 4k6, 4k4, 2k5, ValleyView2HD ausschaut. Weißt du, wie es hier mit DX12 Treibern ausschaut?!

Anyway:
Laut Steam HW Survey spricht nichts gegen reine DX12 Spiele, da die Hardwareverbreitung breit genug ist. Software steht dem auch (noch) nicht im Wege, da Windows 10 (noch) kostenlos verteilt wird...

Und jetzt werfen wir mal einen BLick auf den Marktanteil von Windows 10 (32+64bit):
~18%....
Nach etwa 6 Wochen, 18% Marktanteil....


Marktanteil von WIndows 10/64bit:
0,76% im April
0,87% im Mai
1,1% im Juni
3,35% im Juli
17,11% im Augus (!!!!!!!!!!!!!!!!!!!)

[Timbaloo]

Ob es nun zwei Renderpfade DX11+DX12 oder zwei Renderpfade DX12(NV)+DX12(AMD) gibt ändert jetzt an dem Thema genau was?

[DinosaurusRex]

Ich denke es wird generell ignoriert, wie krampfhaft Microsoft versucht, Win10 an den Mann zu bringen. Die verschenken das nicht weil sie dieses Jahr einfach gut drauf sind. Microsoft macht nur einen Bruchteil des Umsatzes mit der Xbox. DX12 ist Win10-exklusiv. Ich wette die werden DX12 Games pushen.

[Isen]

Anreize für DX12=Win10 schaffen, jo. Denke ich auch.

[deekey777]

Ob es nun zwei Renderpfade DX11+DX12 oder zwei Renderpfade DX12(NV)+DX12(AMD) gibt ändert jetzt an dem Thema genau was?
Irgendein Depp muss das ja machen. Und da jemand den Depp bezahlen muss, wird dieser Jemand sich fragen, warum er das Geld nicht in etwas sinnvolleres investieren soll. DirectX 11 ist ein toller gemeinsamer Nenner.

[Arcanoxer]

Anyway:
Laut Steam HW Survey spricht nichts gegen reine DX12 Spiele, da die Hardwareverbreitung breit genug ist. Software steht dem auch (noch) nicht im Wege, da Windows 10 (noch) kostenlos verteilt wird...

Da wird gar nichts kostenlos verteilt.
Du bezahlst mit deiner alten Windows Lizenz und deiner Privatsphäre am Desktop.

[aufkrawall]

Das eine stimmt nicht und gegen das andere kann man etwas tun.

[Timbaloo]

Irgendein Depp muss das ja machen. Und da jemand den Depp bezahlen muss, wird dieser Jemand sich fragen, warum er das Geld nicht in etwas sinnvolleres investieren soll. DirectX 11 ist ein toller gemeinsamer Nenner.
Die Entwickler wollten doch low-level-APIs? Dann dürfen sie jetzt über die negativen Konsequenzen (mehr Arbeit durch weniger Abstraktion) ihrer Forderung nicht meckern. Das wäre ja lächerlich.

Oder verstehe ich dich falsch?

[Tesseract]

Du bezahlst mit deiner alten Windows Lizenz und deiner Privatsphäre am Desktop.

soweit ich weiß bleibt die alte lizenz erhalten. sobald man upgradet wird W10 für die aktuelle hardware-ID freigeschalten und wenn man z.B. das board tauscht und W10 nichtmehr aktiviert muss man wohl jedes mal wieder den weg altes OS->upgrade(->clean install) gehen wenn man sich nicht an den support wenden will. scheint ziemlich schwachsinnig zu sein das ganze.

[dargo]

Da wird gar nichts kostenlos verteilt.
Du bezahlst mit deiner alten Windows Lizenz...
Bitte informiere dich vorher richtig bevor du wieder FUD verbreitest.

[StefanV]

Da wird gar nichts kostenlos verteilt.
Du bezahlst mit deiner alten Windows Lizenz und deiner Privatsphäre am Desktop.
FUD ALARM!!

Das ganze sind mal wieder Falschaussagen...
Was treibt dich n ur immer wieder dazu solch einen Mist zu verbreiten?! Hast sonst nix zu tun?!

Anyway:
1. Inkorrekt. Die alte Lizenz leibt bestehen, man bekommt 'nur' die Hardware auf der man Win10 installiert freigeschaltet...

2. ORLY?!
Und auf deinem iOS oder ANdroiden stört dich sowas mal überhaupt nicht. Warum ist das so, dass das nur bei Windows stört?!
Oh und Unter Linux schauts ja teilweise nicht anders aus - interessiert halt niemanden, ist halt nicht M$, den man damit Bashen könnte...

[Arcanoxer]

soweit ich weiß bleibt die alte lizenz erhalten. sobald man upgradet wird W10 für die aktuelle hardware-ID freigeschalten und wenn man z.B. das board tauscht und W10 nichtmehr aktiviert muss man wohl jedes mal wieder den weg altes OS->upgrade(->clean install) gehen wenn man sich nicht an den support wenden will. scheint ziemlich schwachsinnig zu sein das ganze.Seit wann das denn?
Am Anfang war doch immer die rede davon das die alte Lizenz mit ein Upgrade wertlos wird?!
Dadurch kenne ich so einige Leute die aufgrund dessen nicht vor haben auf Windows 10 Upzugraden, weil ihn die alte Lizenz wichtiger war. ;D

Blöd genug von MS dort nicht von Anfang an mehr Transparenz rein zu bringen.

[BlacKi]

Blöd genug von MS dort nicht von Anfang an mehr Transparenz rein zu bringen.
du meinst das dass nicht in der fernsehwerbung kommt? hier im forum, bei pcgh, sogar bei microsoft konnte man das nachlesen. hattest du 6 monate pc und handy verbot?^^

btw. its OT

[Unicous]

@Tesseract

Warum gehst du darauf ein? Ist doch offensichtlich ein Trollversuch. Und es hat geklappt. Thread erfolgreich derailed.

[Arcanoxer]

du meinst das dass nicht in der fernsehwerbung kommt? hier im forum, bei pcgh, sogar bei microsoft konnte man das nachlesen. hattest du 6 monate pc und handy verbot?^^

btw. its OT
Hier im forum und bei pcgh ging aber genau so die Meldung rum, das eben beim "Upgrade" die alte Lizenz verloren geht.

Mit Fernsehwerbung könntest du mich schon mal nicht erreichen, wie wäre es denn mit ein Hinweis beim penetranten Upgrade-Popup die Information mit unterzubringen?
Wäre vermutlich zu einfach gewesen. :uponder:

@Tesseract

Warum gehst du darauf ein? Ist doch offensichtlich ein Trollversuch. Und es hat geklappt. Thread erfolgreich derailed.
forums analyst strikes back. ;D

[Kriton]

Auch wenn es (sehr) OT ist: Ich dachte auch man verliert die alte Lizenz (Upgrade ohne Downgrademöglichkeit nach dem 1. Jahr) und hat (lediglich) im 1. Jahr die Möglichkeit wieder zurückzukehren.
Doppelte Lizenzausstattung wäre mir neu.

[dargo]

Und jetzt werfen wir mal einen BLick auf den Marktanteil von Windows 10 (32+64bit):
~18%....
Nach etwa 6 Wochen, 18% Marktanteil....


Marktanteil von WIndows 10/64bit:
0,76% im April
0,87% im Mai
1,1% im Juni
3,35% im Juli
17,11% im Augus (!!!!!!!!!!!!!!!!!!!)
So siehst aus. Windows 10 setzt sich imo voll durch.
53165

http://store.steampowered.com/hwsurvey/directx/

[Gipsel]

Async Compute und Preepmtion sind zwei voellig getrennte Probleme. Du kannst GPUs haben die Async unterstuetzen und trotzdem nicht in der Lage sind einen Workload zu unterbrechen waehrend er laeuft. Und ich bin mir auch relativ sicher, dass das bei zumindest frueheren GCN-GPUs so ist.So wie ich das verstehe, mußt Du bei GCN gar nicht Preemption machen in dem Sinne, daß Du laufende Shader unterbrichst. Bei GCN ist die Granularität des Schedulings durch z.B. die ACEs eine einzelne Wavefront (bzw. thread group). Sobald auf irgendeiner CU genügend Resourcen dafür frei sind, kann das dort ausgeführt werden, ohne das ein Kontext Switch nötig ist oder andere laufende Shader aus dem gleichen oder anderen Kontext beendet werden müssen. Man kann die schlicht simultan laufen lassen und so aus dem Überlapp profitieren. Kommt z.B. ein Compute Shader dazu, werden eventuell noch freie Resourcen der GPU sofort damit gefüllt und bei Beendigung einzelner Wavefronts/Threadgroups der bereits laufenden Shader werden sukzessive mehr und mehr Wavefronts des Compute Shaders gestartet. Hat der Compute Shader eine höhere Priorität als die bereits vorher laufenden Shader verpaßt bekommen (das geht wohl momentan höchstens über Profile im Treiber und ist nicht unter Entwicklerkontrolle, oder?), verdrängt er mit der Zeit die anderen Shader zum großen Teil, bei gleicher Priorität werden die Resourcen wohl mehr oder weniger fair gesplittet.
Zumindest sollte so nach meinem Verständnis die Hardware funktionieren. Sie kann simultan an mehreren Kontexten arbeiten und die Ausführung überlappen, nV-GPUs können das wohl im Moment noch nicht. NV empfahl ja z.B. Tiling bei längeren Postprocessing-Shadern, wobei man die einzelnen Tiles dann in verschiedenen Drawcalls abarbeitet, damit zwischen den Tiles irgendwas einschieben kann. Das ist bei GCN unnötig, da die Shader eben mit Wavefront-Granularität gescheduled werden können, was also bei dem Beispiel in nV-Analogie eine Art automatisches Screentiling mit Blöcken von jeweils 64 Pixeln (oder wie auch immer man das im PP-Pass auf die Threads respektive Wavefronts mapped) ergibt, auch wenn man die Berechnung für ein Fullscreen-Quad in einem einzigen Drawcall losschickt. GCN kann immer noch einen Computeshader dazwischen schieben (ohne den PP-Pass zu unterbrechen), nV offenbar nicht. NV macht die "Preemption" laut eigener Aussage auf Drawcall-Level (was ja im Sinne des Wortes eigentlich gar keine ist), GCN kann das auf Wavefront-Ebene.

[BlacKi]

So siehst aus. Windows 10 setzt sich imo voll durch.
53165

http://store.steampowered.com/hwsurvey/directx/
etwas mehr realismus bitte. klar wird früher oder später win 10 das windows sein das am meisten benutzt wird. aber leute die pc´s im mediamarkt kaufen wechseln wohl erst mit einem neuen rechner.

wie kann man von einer durchsetzung reden wenn trotz kostenlosem wechsel und dem release im august windows 7 nur läpische 5% verliert. mit abstand immernoch das meistbenutzte windows.

die steigerung von win10 wird im september niedriger ausfallen, weil kein release stattfindet auf den die user warten.

ich erwarte bis ende des jahres maximal 25-30% der steam user die windows 10 nutzen und somit dx12 unterstützung haben.

[Menace]

Der typische Steam-Nutzer, der sein PC wegen Spiele kauft ist uninformiert und nimmt nicht ein geschenkte Window-Version an? Glaube ich nicht, zumal Microsoft ja es einem wirklich einfach macht mit dem Upgrade-Möglichkeiten.

[BlacKi]

Der typische Steam-Nutzer, der sein PC wegen Spiele kauft ist uninformiert und nimmt nicht ein geschenkte Window-Version an? Glaube ich nicht, zumal Microsoft ja es einem wirklich einfach macht mit dem Upgrade-Möglichkeiten.
ich kenne einige die das popup haben aber nicht wechseln wollen. zum anderen heißt es doch, kaufe windows nie vor dem ersten service pack.

[del_4901]

@Gipsel, @Novum

Ich muss da zustimmen, dass AsyncCompute und Preemption zwei getrennte Sachen sind. AsyncCompute geht nur solange wie Resourcen (in Form von Registern und LocalMemory) zur Verfuegung stehen. Sind die voll belegt kann man nichts mehr dazwischen quetschen. Preemption hingehen kann tasks die auf der GPU laufen in bestimmter Granularitaet unterbrechen und die verbleibenden Tasks auslagern und spaeter laufen lassen.

[Gipsel]

@Gipsel, @Novum

Ich muss da zustimmen, dass AsyncCompute und Preemption zwei getrennte Sachen sind. AsyncCompute geht nur solange wie Resourcen (in Form von Registern und LocalMemory) zur Verfuegung stehen. Sind die voll belegt kann man nichts mehr dazwischen quetschen. Preemption hingehen kann tasks die auf der GPU laufen in bestimmter Granularitaet unterbrechen und die verbleibenden Tasks auslagern und spaeter laufen lassen.Das ist doch völlig klar, daß bei nichtvorhandenen freien Resourcen auch nichts ausgeführt werden kann. Das schrieb ich ja selber schon. Preemption im Sinne, daß wirklich laufende Shader unterbrochen werden, wird ja auf GPUs praktisch nicht gemacht. Die von nV so genannte "Preemption" mit Kontext-Switch an Drawcall boundaries ist ja eher kooperativ als preemptiv. Der Unterschied bei AMD-GPUs ist nun vermutlich, daß der Kontext-Switch schlicht überflüssig ist, da einfach mehrere gleichzeitig aktiv sein können (vermutlich mit gewissen Einschränkungen, aber offensichtlich geht es unter bestimmten Umständen). Die GPU muß also nicht bis zum Ende des Drawcalls warten, um Wavefronts eines anderen Kontextes starten zu können, sondern nur bis zum Ende irgendeiner Wavefront (Threadgroup in DX-Sprech, gegebenenfalls mehrerer), weil bei deren Ende Resourcen frei werden und dann schlicht Wavefronts verschiedener Shader verschiedener Kontexte gleichzeitig ans Shaderarray geschickt werden können. Die Latenz bzw. Granularität der "Preemption" (der Begriff trifft es hier auch nicht, weil kein Kontext-Switch stattfindet, bzw. nicht für die ganze GPU, sondern nur für einzelne Ausführungs"slots" von Wavefronts in den CUs) ist dann nicht die Dauer des kompletten Drawcalls sondern nur die der Ausführung einer einzelnen Wavefront (gegebenenfalls weniger, falls noch Resourcen frei waren). Tja, und das hilft dann natürlich in bestimmten Situationen mit ASync Compute Shadern.

Edit:
Angeblich sagt nV jetzt, daß ihr Treiber unter DX12 bei Async-Compute noch Blödsinn macht. Also vielleicht ist da Besserung in Sicht.

[del_4901]

Das ist doch völlig klar, daß bei nichtvorhandenen freien Resourcen auch nichts ausgeführt werden kann. Das schrieb ich ja selber schon. Preemption im Sinne, daß wirklich laufende Shader unterbrochen werden, wird ja auf GPUs praktisch nicht gemacht. Die von nV so genannte "Preemption" mit Kontext-Switch an Drawcall boundaries ist ja eher kooperativ als preemptiv. Der Unterschied bei AMD-GPUs ist nun vermutlich, daß der Kontext-Switch schlicht überflüssig ist, da einfach mehrere gleichzeitig aktiv sein können (vermutlich mit gewissen Einschränkungen, aber offensichtlich geht es unter bestimmten Umständen). Die GPU muß also nicht bis zum Ende des Drawcalls warten, um Wavefronts eines anderen Kontextes starten zu können, sondern nur bis zum Ende irgendeiner Wavefront (Threadgroup in DX-Sprech, gegebenenfalls mehrerer), weil bei deren Ende Resourcen frei werden und dann schlicht Wavefronts verschiedener Shader verschiedener Kontexte gleichzeitig ans Shaderarray geschickt werden können. Die Latenz bzw. Granularität der "Preemption" (der Begriff trifft es hier auch nicht, weil kein Kontext-Switch stattfindet, bzw. nicht für die ganze GPU, sondern nur für einzelne Ausführungs"slots" von Wavefronts in den CUs) ist dann nicht die Dauer des kompletten Drawcalls sondern nur die der Ausführung einer einzelnen Wavefront (gegebenenfalls weniger, falls noch Resourcen frei waren). Tja, und das hilft dann natürlich in bestimmten Situationen mit ASync Compute Shadern.Preemption ist nicht ueberfluessig, weil man ohne solche die GPU einfach deadlocken kann. Das geht z.B. ganz einfach wenn mehrere Prozesse auf comandbuffer warten aber jeder Prozess individuell ganz vorne in der Queue steckt. Mit Preemption laesst sich das Problem einfach loesen, mit AsyncCompute allein noch nicht.

[Gipsel]

Preemption ist nicht ueberfluessig, weil man ohne solche die GPU einfach deadlocken kann. Das geht z.B. ganz einfach wenn mehrere Prozesse auf comandbuffer warten aber jeder Prozess individuell ganz vorne in der Queue steckt. Mit Preemption laesst sich das Problem einfach loesen, mit AsyncCompute allein noch nicht.
Für die beschriebene Problematik, daß man einen (unabhängigen) Compute Shader in die laufende Ausführung irgendeines anderen Shaders einschiebt (die dann simultan laufen), benötigt man keine Preemption im Sinne der Unterbrechung der Ausführung eines Shaders, also wie man das auf CPUs gemeinhin versteht. Abwarten, bis der Drawcall komplett durch das Shaderarray der GPU ausgeführt wurde (nV), verdient diesen Begriff eigentlich kaum. Auch beim Abwarten, bis ein Hardwarethread (Wavefront/Threadgroup) der GPU einen kleinen Teil der kompletten Ausführungsdomäne abgearbeitet hat (AMD), ist das irgendwie schwierig. Das wäre eher sowas wie coarse bzw. fine grained kooperatives Scheduling (allerdings auf einer massiv multithreaded GPU, die gegebenenfalls auch mehrere Prozesse [Kontexte] simultan ausführen kann, die Begrifflichkeiten verschieben sich da also etwas). Vielleicht macht der Begriff mehr Sinn, wenn man sich das aus Sicht des CommandProcessors vorstellt mit den Drawcalls als Instruktionen oder so. Aber egal.

Aber wo soll denn da ein Deadlock ein Problem werden? Die Queues der ACEs sind zum einen keine strikten FIFO-Queues, die können auch OoO abgearbeitet werden, je nachdem, welche Resourcen bereit sind (bzw. mit was man synchronisiert). Und wenn für einen Kernel noch irgendwas fehlt, werden auch keine Ausführungseinheiten/Register/local Memory belegt, sondern können von anderen (bei denen Alles bereit ist) benutzt werden. Und es ist ja nicht so, daß einem Shader A erst mitten bei der Ausführung mit einem Mal einfällt: Oops, ich brauche ja noch den Buffer xyz, den Shader B erst erzeugen muß, der kann jetzt aber nicht loslaufen, weil ja schon Shader A läuft und alle Ausführungsresourcen blockiert. Das weiß man ja vorher, so daß diese Deadlocksituation nicht vorkommen kann (und stellt dann im Zweifelsfall über Barrieren die korrekte Ausführung sicher, oder etwa nicht?).

[Nightspider]

Bin mal gespannt wofür ASC genau bei neuen Spielen wie Tomb Raider 2016 verwendet wird und wie dann Nvidia Karten performen werden.

[Hübie]

Dann muss bei preemption auch konstant Priorität gesetzt werden, sonst hat man ja wieder den Fall, das erst eine Threadgroup durchlaufen muss. Frage ist nun wieviele priority flags können gesetzt werden und ob dies Sache des Coders ist, oder ob der Scheduler das erteilt? Ich kann mir denken, dass dies in der ISA von AMDs GCN drin steht. nVidia gibt so etwas ja nicht offiziell heraus :rolleyes:
Und was noch interessiert: Wo werden die "gestoppten" Shader ausgelagert? L1 ist ja doch ziemlich begrenzt. Eher L2$?

@Gipsel: Woher hast du die Info dass nVidia behauptet deren Treiber mache noch Schwierigkeiten? Würde zumindest meine Ergebnisse von dem ollen Test etwas erklären.

[Unicous]

[...] We actually just chatted with Nvidia about Async Compute, indeed the driver hasn't fully implemented it yet, but it appeared like it was. We are working closely with them as they fully implement Async Compute. We'll keep everyone posted as we learn more.[...]


http://www.overclock.net/t/1569897/various-ashes-of-the-singularity-dx12-benchmarks/2130#post_24379702

Von Interesse ist auch dieser Kommentar von David Kanter beim TR-podcast( via http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10767113#post10767113):

https://www.youtube.com/watch?v=tTVeZlwn9W8&feature=youtu.be&t=1h21m35s

[Gipsel]

Dann muss bei preemption auch konstant Priorität gesetzt werden, sonst hat man ja wieder den Fall, das erst eine Threadgroup durchlaufen muss. Frage ist nun wieviele priority flags können gesetzt werden und ob dies Sache des Coders ist, oder ob der Scheduler das erteilt? Ich kann mir denken, dass dies in der ISA von AMDs GCN drin steht.Ja, aber da kommt man über die normalen APIs wohl eher schwer ran. Deswegen meinte ich ja, daß sowas noch am ehesten von irgendwelchen Profilen im Treiber gesetzt wird.
Und was noch interessiert: Wo werden die "gestoppten" Shader ausgelagert? L1 ist ja doch ziemlich begrenzt. Eher L2$?Wie ich schon sagte, stoppt bisher eigentlich kaum jemand Shader auf GPUs. Preemption wie auf CPUs mit Sicherung und Wiederherstellung des kompletten Prozessorzustandes funktioniert vielleicht irgendwo rudimentär, aber die Performanceverluste bei ständiger interruptgesteuerter Preemption (z.B. 1ms Granularität, also mit 1 KHz) wären wohl merklich (ein Fiji hat über 20MB Register und local Memory, 328kB pro CU). Da ist von Ausnahmefällen abgesehen ein eher kooperativer Ansatz über Prioritäten und der gleichzeitigen Ausführung mehrerer Prozesse vermutlich sinnvoller.

[Hübie]

Er sagt exakt das was ich damals schon sagte: Maxwell hat ne Menge scheduling rausgeschmissen und macht das nun per Firmware. Vorteil: Flexibilität. Nachteil: Kostet Latenz und ist anfällig.

Es hat sich ja immer noch kein Titan-User erbarmt den async-test mal unter Windows 10 zu fahren... :(

@Gipsel: GCN ist allgemein sehr speicherlastig im Vergleich zu Kepler / Maxwell. Dennoch bin ich sicher, dass auch Maxwell asynchrone Shader effizienter, als jetzt mit Ashes of Singularity dargestellt, abarbeiten kann.
Ich bräuchte mal ne GK210 hier. Oder wenigstens eine Titan / Titan Black... Wenn meine Theorie stimmt, müssten die in diesem Benchmarktool besser abschneiden.

Edit: Und ehrlich gesagt weiß ich gar nicht warum es hier vielen so wichtig ist dass dies in Hardware gegossen ist? :| Wenn die Software-Lösung nicht Müll ist, kann das beinahe egal sein. Erst wenn es mehrere Millisekunden (sagen wir >5) kostet wird es zum echten Nachteil. Das ist auch keine Voraussetzung für die D3D12(Tier2)-Spezifikation.

Ja, aber da kommt man über die normalen APIs wohl eher schwer ran. Deswegen meinte ich ja, daß sowas noch am ehesten von irgendwelchen Profilen im Treiber gesetzt wird.
Also würde man das nicht mal mit nem Visual Debugger sehen (nur vermuten)... oder?

[Novum]

Er sagt exakt das was ich damals schon sagte: Maxwell hat ne Menge scheduling rausgeschmissen und macht das nun per Firmware. Vorteil: Flexibilität. Nachteil: Kostet Latenz und ist anfällig.
Das scheduling in den CUs hat nichts, aber auch gar nichts mit async conpute oder irgend welchen Latenzen zu tun.

Überdies ist GCN was dieses Scheduling angeht noch viel primitiver als Maxwell. Was keine schlechte Sache ist.

[Novum]

Ja, aber da kommt man über die normalen APIs wohl eher schwer ran. Deswegen meinte ich ja, daß sowas noch am ehesten von irgendwelchen Profilen im Treiber gesetzt wird.
Wie ich schon sagte, stoppt bisher eigentlich kaum jemand Shader auf GPUs. Preemption wie auf CPUs mit Sicherung und Wiederherstellung des kompletten Prozessorzustandes funktioniert vielleicht irgendwo rudimentär, aber die Performanceverluste bei ständiger interruptgesteuerter Preemption (z.B. 1ms Granularität, also mit 1 KHz) wären wohl merklich (ein Fiji hat über 20MB Register und local Memory, 328kB pro CU). Da ist von Ausnahmefällen abgesehen ein eher kooperativer Ansatz über Prioritäten und der gleichzeitigen Ausführung mehrerer Prozesse vermutlich sinnvoller.
Ich denke man kommt auch mit 100Hz auf der GPU hin und verglichen mit der Speicherbandbreite sind das jetzt auch nicht so viele Daten.

Kooperativ wird nie funktionieren, es gibt jetzt schon Bugs in Spielen die einen Drawcall erzeugen der eine Endlosschleife hat worauf der Watchdog-Timer den ganzen Treiber abschießt. Das ist sowas von ghetto in 2015.

[Hübie]

Das scheduling in den CUs hat nichts, aber auch gar nichts mit async conpute oder irgend welchen Latenzen zu tun.

Überdies ist GCN was dieses Scheduling angeht noch viel primitiver als Maxwell. Was keine schlechte Sache ist.

Ich meinte in dem Falle auch nicht das scheduling für async sondern allgemein fürs setup. Habe ich nicht gesagt - my fault.
Damals hatte ich im TS ein "Streitgespräch" mit einem Forenmitglied dass einfach nicht glauben wollte, dass man bei Maxwell mehr rausgeschmissen hat, als nach Fermi bei Kepler reingenommen wurde. Nun habe ich es zum ersten Mal von jemand anderen gehört und man kanns abrufen. :D

Edit: Wäre Scheduling des Arbiter hier besser angebracht gewesen?

Übrigens finde ich dieses Statement (https://forum.beyond3d.com/posts/1870218/) sehr passend:

No, it is blending them together just fine. One queue is filled commands from the render pipeline. The other 31 queues are either filled with commands from up to 31 dedicated (software) queues or with async tasks.

That's almost working as it is supposed to. There appear to be several distinct problem though:

If a task is flagged as async, it is never batched with other tasks - so the corresponding queue underruns as soon as the assigned task finished.
If a queue is flagged as async AND serial, apart from the lack of batching, all other 31 queues are not filled in either, so the GPU runs out of jobs after executing just a single task each.
As soon as dependencies become involved, the entire scheduling is performed on the CPU side, as opposed to offloading at least parts of it to the GPU.
Mixed mode (31+1) seems to have different hardware capabilities than pure compute mode (32). Via DX12, only mixed mode is accessible. (Not sure if this is true or if just the driver isn't making use of any hardware features.)
The graphic part of the benchmark in this thread appears to keep the GPU completely busy on Nvidia hardware, so none of the compute tasks is actually running "parallel".
"Real" compute tasks require the GPU to be completely idle first before switching context. This became prominent as Windows is dispatching at least one pure compute task on a regular base, which starved and caused Windows to kill the driver.

Well, at least the first two are apparently driver bugs:

Nvidia COULD just merge multiple async tasks into batches in order to avoid underruns in the individual queues. This would reduce the number of roundtrips to the CPU enormously.
Same goes for sequential tasks, they can be merged in batches as well. AMD already does that, and even performes additional optimizations on the merged code (notice how the performance went up in sequential mode?).

So AMD's driver is just far more matured, while Nvidia is currently using a rather naive approach only.



Well, and there's the confirmation.

I wouldn't expect the Nvidia cards to perform THAT bad in the future, given that there are still possible gains to be made in the driver. I wouldn't exactly overestimate them either, though. AMD has just a far more scalable hardware design in this domain, and the necessity of switching between compute and graphic context in combination with the starvation issue will continue to haunt Nvidia as that isn't a software but a hardware design fault.

[dargo]

Ob die Schenkungsaktion tatsächlich ehr an die Zocker gerichtet war, ist die Frage.
Natürlich, schon dieses Bild vergessen?
http://s28.postimg.org/rls41z7x9/thumb900_php39q0jjp1010645.jpg

Das sind verdammt hohe Ziele die man sich da gesetzt hat.

Bin mal gespannt wofür ASC genau bei neuen Spielen wie Tomb Raider 2016 verwendet wird und wie dann Nvidia Karten performen werden.
http://gearnuke.com/rise-of-the-tomb-raider-uses-async-compute-to-render-breathtaking-volumetric-lighting-on-xbox-one/#

[del_4901]

Für die beschriebene Problematik, daß man einen (unabhängigen) Compute Shader in die laufende Ausführung irgendeines anderen Shaders einschiebt (die dann simultan laufen), benötigt man keine Preemption im Sinne der Unterbrechung der Ausführung eines Shaders, also wie man das auf CPUs gemeinhin versteht. Abwarten, bis der Drawcall komplett durch das Shaderarray der GPU ausgeführt wurde (nV), verdient diesen Begriff eigentlich kaum. Auch beim Abwarten, bis ein Hardwarethread (Wavefront/Threadgroup) der GPU einen kleinen Teil der kompletten Ausführungsdomäne abgearbeitet hat (AMD), ist das irgendwie schwierig. Das wäre eher sowas wie coarse bzw. fine grained kooperatives Scheduling (allerdings auf einer massiv multithreaded GPU, die gegebenenfalls auch mehrere Prozesse [Kontexte] simultan ausführen kann, die Begrifflichkeiten verschieben sich da also etwas). Vielleicht macht der Begriff mehr Sinn, wenn man sich das aus Sicht des CommandProcessors vorstellt mit den Drawcalls als Instruktionen oder so. Aber egal.

Aber wo soll denn da ein Deadlock ein Problem werden? Die Queues der ACEs sind zum einen keine strikten FIFO-Queues, die können auch OoO abgearbeitet werden, je nachdem, welche Resourcen bereit sind (bzw. mit was man synchronisiert). Und wenn für einen Kernel noch irgendwas fehlt, werden auch keine Ausführungseinheiten/Register/local Memory belegt, sondern können von anderen (bei denen Alles bereit ist) benutzt werden. Und es ist ja nicht so, daß einem Shader A erst mitten bei der Ausführung mit einem Mal einfällt: Oops, ich brauche ja noch den Buffer xyz, den Shader B erst erzeugen muß, der kann jetzt aber nicht loslaufen, weil ja schon Shader A läuft und alle Ausführungsresourcen blockiert. Das weiß man ja vorher, so daß diese Deadlocksituation nicht vorkommen kann (und stellt dann im Zweifelsfall über Barrieren die korrekte Ausführung sicher, oder etwa nicht?).
Preemption braucht man vor allem wenn man mehrere GFX tasks am laufen hat (mehrere prozesse gleichzeitig). Die queues sind naemlich FIFO queues in wenn ein prozess die alle mit wartenden tasks befuellt ein anderer die GFX queue belegt und auf Compute work wartet, dann wars das. Deswegen macht mn das scheduling auf dem PC immernoch auf der CPU. Barrieren helfen hier nicht da man nicht wissen kann was der andere Prozess macht. (z.B ein Game vs. Browser). Es gibt auch Fälle wo waves auf Arbeit warten und Spinlocken.
Preemption hilft erstmal gar nicht um die Auslastung zu erhöhen. Die bringt nur was wenn man mal schnell einen super wichtigen low latency task durchschieben will.

[fondness]

Der letzte Satz fasst eigentlich eh alles zusammen:

"I wouldn't expect the Nvidia cards to perform THAT bad in the future, given that there are still possible gains to be made in the driver. I wouldn't exactly overestimate them either, though. AMD has just a far more scalable hardware design in this domain, and the necessity of switching between compute and graphic context in combination with the starvation issue will continue to haunt Nvidia as that isn't a software but a hardware design fault."

Aktuell haben sie ja negativ scaling mit AsyncCompute, die Frage ist also ob sie es überhaupt schaffen, AsyncCompute ohne Performaceeinbruch auszuführen. Denn das ganze was er vorschlägt mit dem Zusammenfassen, bedeutet ja letztendlich, das man es eben nicht mehr async ausführt, es also einfach kein Nachteil mehr ist. Ob NV von asnyc compute ohne die entsprechende Hardware allerdings auch einen Vorteil ziehen kann ist damit noch lange nicht gesagt und dürfte wohl eher unwahrscheinlich sein.

[Gipsel]

Ich denke man kommt auch mit 100Hz auf der GPU hin und verglichen mit der Speicherbandbreite sind das jetzt auch nicht so viele Daten.Aber wenn Du noch kurz was Wichtiges an beliebiger Stelle einschieben willst (kurz vor VSync?), dann wären meiner Meinung nach 1 kHz fast schon Minimum (viele Spiele oder andere Anwendungen [Mediaplayer] haben mit 10ms Task-Scheduling-Granularität von Windows auch recht massive Performance-Einbrüche, weswegen das meist auf 1ms runtergedreht wird ;)). Nur zum Abschießen unresponsiver Drawcalls reicht natürlich weniger.
Preemption braucht man vor allem wenn man mehrere GFX tasks am laufen hat (mehrere prozesse gleichzeitig). Die queues sind naemlich FIFO queues in wenn ein prozess die alle mit wartenden tasks befuellt ein anderer die GFX queue belegt und auf Compute work wartet, dann wars das. Deswegen macht mn das scheduling auf dem PC immernoch auf der CPU. Barrieren helfen hier nicht da man nicht wissen kann was der andere Prozess macht. (z.B ein Game vs. Browser). Es gibt auch Fälle wo waves auf Arbeit warten und Spinlocken.Letzteres kannst Du heutzutage aber nur schwer extern unterbrechen. Die Preemption von der Du redest betrifft (wie schon vermutet) den Commandprocessor. Ich hatte das eher auf das eigentliche Shaderarray bezogen.
Preemption hilft erstmal gar nicht um die Auslastung zu erhöhen. Die bringt nur was wenn man mal schnell einen super wichtigen low latency task durchschieben will.Ohne Unterbrechung der laufenden Threads auf dem Shaderarray hat das dann aber auch keine garantierte niedrige Latenz (auch AMDs Ansatz nicht, auch wenn sie deutlich niedriger ist). Und diese Unterbrechung gibt es momentan praktisch nicht. Der avisierte Ausweg sind wohl mehrere (priorisierte) GFX-Queues, die das ähnlich wie die ACEs für Compute handhaben.
Und deswegen ja auch meine These, daß man dafür nicht unbedingt Preemption mitsamt Kontext-Switch für die ganze GPU benötigt, sondern für Vieles auch eine feinere Granularität des Schedulings aus mehreren Queues (und/oder OoO aus einer) und simultane Ausführung mehrerer Kontexte reichen kann. Die "echte" Preemption brauchst Du dann nur für Situationen mit "unkooperativen" Partnern, also wenn tatsächlich die komplette GPU belegt wird und man die Waves in einem Loop/Spinlock festhängen (was eigentlich nicht passieren sollte). Also im Prinzip für solche Situationen:
Kooperativ wird nie funktionieren, es gibt jetzt schon Bugs in Spielen die einen Drawcall erzeugen der eine Endlosschleife hat worauf der Watchdog-Timer den ganzen Treiber abschießt. Das ist sowas von ghetto in 2015.

[del_4901]

Aber wenn Du noch kurz was Wichtiges an beliebiger Stelle einschieben willst (kurz vor VSync?), dann wären meiner Meinung nach 1 kHz fast schon Minimum (viele Spiele oder andere Anwendungen [Mediaplayer] haben mit 10ms Task-Scheduling-Granularität von Windows auch recht massive Performance-Einbrüche, weswegen das meist auf 1ms runtergedreht wird ;)). Nur zum Abschießen unresponsiver Drawcalls reicht natürlich weniger.
Letzteres kannst Du heutzutage aber nur schwer extern unterbrechen. Die Preemption von der Du redest betrifft (wie schon vermutet) den Commandprocessor. Ich hatte das eher auf das eigentliche Shaderarray bezogen.
Ohne Unterbrechung der laufenden Threads auf dem Shaderarray hat das dann aber auch keine garantierte niedrige Latenz (auch AMDs Ansatz nicht, auch wenn sie deutlich niedriger ist). Und diese Unterbrechung gibt es momentan praktisch nicht. Der avisierte Ausweg sind wohl mehrere (priorisierte) GFX-Queues, die das ähnlich wie die ACEs für Compute handhaben.
Und deswegen ja auch meine These, daß man dafür nicht unbedingt Preemption mitsamt Kontext-Switch für die ganze GPU benötigt, sondern für Vieles auch eine feinere Granularität des Schedulings aus mehreren Queues (und/oder OoO aus einer) und simultane Ausführung mehrerer Kontexte reichen kann. Die "echte" Preemption brauchst Du dann nur für Situationen mit "unkooperativen" Partnern, also wenn tatsächlich die komplette GPU belegt wird und man die Waves in einem Loop/Spinlock festhängen (was eigentlich nicht passieren sollte). Also im Prinzip für solche Situationen:
Preemtion in der noetigen Form gibt es nicht auf GPUs. Priorisierte Queues helfen dir dabei aber auch nicht, da ein einziger Drawcall (mit und ohne Tess) easy die komplette GPU flodden kann, und dann ist einfach kein Platz mehr fuer einen weiteren high Prio Task.

[Gipsel]

Preemtion in der noetigen Form gibt es nicht auf GPUs.Sage ich ja.
Priorisierte Queues helfen dir dabei aber auch nicht, da ein einziger Drawcall (mit und ohne Tess) easy die komplette GPU flodden kann, und dann ist einfach kein Platz mehr fuer einen weiteren high Prio Task.Die helfen insofern, als die Resource Allocation (also Register, local memory) auf Wavefront/Threadgroup-Ebene geschieht. Man blockiert nicht mit einem Drawcall die Resourcen der GPU für die Dauer des Drawcalls (okay, auf nV momentan anscheinend schon). Der Dispatch von Wavefronts aus den verschiedenen Queues ist deutlich flexibler. Wird irgendeine Wavefront irgendeines Shaders fertig, stehen die davon benutzten Resourcen wieder zur Neuverteilung zur Verfügung und es wird anhand eines Prioritätssystems ausgeknobelt, welcher Shader/Task die danach bekommt. Das muß nicht der gleiche sein ;). Die Resourcennutzung der Shader kann (und wird) sich im Laufe eines Drawcalls dynamisch und flexibel ändern. Die Granularität dafür ist die Laufzeit einer Wavefront, nicht die des Drawcalls.

[Skysnake]

An sich sollte man doch nur auf SMX/4GCN-CU-Block größe mehrere Kontexte halten können.

Also so lange man nicht alle Register braucht kann man doch parallel mehrere Sachen laufen lassen. Und wenn man alle braucht, könnte man ja eine SMX/Block einfach nicht belegen, und ungenutzt lassen, wenn man weiß, das man auch etwas dazwischen schieben können will.

Oder überseh ich da gerade einen großen Hacken, warum das nicht geht?

[del_4901]

Sage ich ja.
Die helfen insofern, als die Resource Allocation (also Register, local memory) auf Wavefront/Threadgroup-Ebene geschieht. Man blockiert nicht mit einem Drawcall die Resourcen der GPU für die Dauer des Drawcalls (okay, auf nV momentan anscheinend schon). Der Dispatch von Wavefronts aus den verschiedenen Queues ist deutlich flexibler. Wird irgendeine Wavefront irgendeines Shaders fertig, stehen die davon benutzten Resourcen wieder zur Neuverteilung zur Verfügung und es wird anhand eines Prioritätssystems ausgeknobelt, welcher Shader/Task die danach bekommt. Das muß nicht der gleiche sein ;). Die Resourcennutzung der Shader kann (und wird) sich im Laufe eines Drawcalls dynamisch und flexibel ändern. Die Granularität dafür ist die Laufzeit einer Wavefront, nicht die des Drawcalls.
Das kann man nicht so einfach machen, wenn die GPU z.B nicht rechtzeitig die Ergebnisse von der Tessellation verarbeitet und alle CUs im Domain/Hull oder Vertexshader export festhängen dann wars das.

[Gipsel]

Das kann man nicht so einfach machen, wenn die GPU z.B nicht rechtzeitig die Ergebnisse von der Tessellation verarbeitet und alle CUs im Domain/Hull oder Vertexshader export festhängen dann wars das.Wieso sollten alle CUs im Hull- oder Domainshader festhaengen? Wenn der Hull-Shader weniger Wavefronts zugeteilt bekommt (der hat typischerweise nicht soo viel zu tun, so dass der nie und nimmer die ganze GPU mit allen CUs belegt, fuer den Rest der Pipeline muss ja auch noch was uebrig bleiben), werden fuer weniger Kontrollpunkte die noetigen Daten berechnet, der Durchsatz sinkt schlicht etwas (der Tessellator hat weniger zu tun und somit auch alle nachfolgenden Stages). Angenommen man entzieht dem Domainshader Resourcen (also man startet einfacher weniger Wavefronts dafuer), wird irgendwann entweder der Tessellator wegen des Backpressure stallen (kein Platz mehr, um die Daten irgendwo zu lassen) oder aber die Parameter werden ueber den L2 in den RAM gestreamt (GCN macht das bei viel Tessellation mit hoeheren Faktoren sowieso, das direkte Schreiben in den local memory der CU, in dem dann die dafuer zustaendige Wavefront mit dem Domainshader gestartet wird, ist nur eine Performanceoptimierung). Der Domainshader kann sich die Daten dann irgendwann holen. Da gibt es keine Deadline, damit es "rechtzeitig" erfolgt. Und weniger Resourcen fuer den Domainshader heisst ja nicht, dass Alles zum Stillstand kommt, es dauert nur laenger, der Hullshader und der Tessellator sind also nicht blockiert. Wenn irgendwas ROP limitiert ist, haengt die GPU ja auch nicht, sondern ist nur im Durchsatz limitiert ;).

[del_4901]

Wieso sollten alle CUs im Hull- oder Domainshader festhaengen? Wenn der Hull-Shader weniger Wavefronts zugeteilt bekommt (der hat typischerweise nicht soo viel zu tun, so dass der nie und nimmer die ganze GPU mit allen CUs belegt, fuer den Rest der Pipeline muss ja auch noch was uebrig bleiben), werden fuer weniger Kontrollpunkte die noetigen Daten berechnet, der Durchsatz sinkt schlicht etwas (der Tessellator hat weniger zu tun und somit auch alle nachfolgenden Stages). Angenommen man entzieht dem Domainshader Resourcen (also man startet einfacher weniger Wavefronts dafuer), wird irgendwann entweder der Tessellator wegen des Backpressure stallen (kein Platz mehr, um die Daten irgendwo zu lassen) oder aber die Parameter werden ueber den L2 in den RAM gestreamt (GCN macht das bei viel Tessellation mit hoeheren Faktoren sowieso, das direkte Schreiben in den local memory der CU, in dem dann die dafuer zustaendige Wavefront mit dem Domainshader gestartet wird, ist nur eine Performanceoptimierung). Der Domainshader kann sich die Daten dann irgendwann holen. Da gibt es keine Deadline, damit es "rechtzeitig" erfolgt. Und weniger Resourcen fuer den Domainshader heisst ja nicht, dass Alles zum Stillstand kommt, es dauert nur laenger, der Hullshader und der Tessellator sind also nicht blockiert. Wenn irgendwas ROP limitiert ist, haengt die GPU ja auch nicht, sondern ist nur im Durchsatz limitiert ;).
Wenn man VS/HS/DS statisch weniger waves zuteilt as dem PS kann es dazu kommen, dass man den Chip nicht auslastet (kleine Dreiecke). Mit einem Prozess und einer Applikation, welche well behaved synchronisiert ist, ist das alles ein loesbares Problem. Kritisch wird es erst wenn man mehrere Prozesse hat wo man nicht mehr weis was sie tun und in welcher Reihenfolge Tasks in die Queues geschoben werden duerfen.

[Gipsel]

Wenn man VS/HS/DS statisch weniger waves zuteilt as dem PS kann es dazu kommen, dass man den Chip nicht auslastet (kleine Dreiecke).Es ging doch gerade darum, Platz fuer andere Shader (z.B. einen Compute Shader) auf der GPU zu schaffen ;).
Und wie gesagt, wird das nicht unbedingt statisch zugeteilt, das geht auch dynamisch. Solange Waves laufen und zum Ende kommen, werden automatisch staendig Resourcen frei, die dann potentiell anderen Shadern (potentiell auch ein anderer Kontext) zugeteilt werden koennen, falls die eine hoehere Prioritaet haben. Fuer die Korrektheit der Ausfuehrung ist es doch voellig egal, ob nun 100 oder 1000 Waves eines Typs gleichzeitig laufen, wenn die GPU z.B. insgesamt 4000 abarbeiten muss (nur fuer die Geschwindigkeit halt nicht).
Kommt ein Shader eines anderen Kontextes mit hoeherer Prioritaet zum Dispatch, werden halt die bereits laufenden Shader etwas zurueckgefahren (in dem weniger neue Waves dafuer gestartet werden und die so mit der Beendigung von Wavefronts freiwerdenden Resourcen zum Starten von Waves des high priority tasks benutzt werden). Falls noch Resourcen auf der GPU frei waren, koennen die zusaetzlich auch direkt gestartet werden. Ausserdem kann man den Waves des high priority Tasks ebenfalls eine erhoehte Prioritaet fuer das Scheduling in den CUs verpassen (das unterstuetzt GCN), so dass die dort bevorzugt bearbeitet werden (die Waves des low priority tasks kommen dann nur bei Stalls bzw. Pipeline bubbles der high priority Waves auf der gleichen CU zum Zuge). Ist der high priority Task fertig, bekommen die Shader des low priority tasks diese Resourcen natuerlich wieder zurueck. Wo ist das Problem?

[del_4901]

Es ging doch gerade darum, Platz fuer andere Shader (z.B. einen Compute Shader) auf der GPU zu schaffen ;).
Und wie gesagt, wird das nicht unbedingt statisch zugeteilt, das geht auch dynamisch. Solange Waves laufen und zum Ende kommen, werden automatisch staendig Resourcen frei, die dann potentiell anderen Shadern (potentiell auch ein anderer Kontext) zugeteilt werden koennen, falls die eine hoehere Prioritaet haben. Fuer die Korrektheit der Ausfuehrung ist es doch voellig egal, ob nun 100 oder 1000 Waves eines Typs gleichzeitig laufen, wenn die GPU z.B. insgesamt 4000 abarbeiten muss (nur fuer die Geschwindigkeit halt nicht).
Kommt ein Shader eines anderen Kontextes mit hoeherer Prioritaet zum Dispatch, werden halt die bereits laufenden Shader etwas zurueckgefahren (in dem weniger neue Waves dafuer gestartet werden und die so mit der Beendigung von Wavefronts freiwerdenden Resourcen zum Starten von Waves des high priority tasks benutzt werden). Falls noch Resourcen auf der GPU frei waren, koennen die zusaetzlich auch direkt gestartet werden. Ausserdem kann man den Waves des high priority Tasks ebenfalls eine erhoehte Prioritaet fuer das Scheduling in den CUs verpassen (das unterstuetzt GCN), so dass die dort bevorzugt bearbeitet werden (die Waves des low priority tasks kommen dann nur bei Stalls bzw. Pipeline bubbles der high priority Waves auf der gleichen CU zum Zuge). Ist der high priority Task fertig, bekommen die Shader des low priority tasks diese Resourcen natuerlich wieder zurueck. Wo ist das Problem?Das Problem ist, dass wenn man eine solche Scheduling Strategie fahren will man immer ein gewisses Resource surplus(Queues, CUs etc.) frei halten muss, das ist aber weder im Interesse des Users, der IHVs oder ISVs. Ansonsten kann es zu deadlocks kommen wenn ProzessA einen TaskA2 hat welcher auf TaskA1 wartet. Und ProzessB hat einen TaskB2 welcher auf TaskB1 wartet. Der HW Scheduler hat keinen Plan wie die Abhaenigkeiten sind, er nimmt einfach das erste Item in den Queues und wartet ggf. bis eine Semaphore frei wird. Angenommen die HW hat 2 Queues die von beiden Prozessen genutzt wird. Aus Sicht der Applikation ist es vollkommen valide erst T1 und spaeter T2 zu queuen. Und wenn B dabei einfach etwas langsamer als A ist, dann kann das ganze so aussehen: Q1: TB1 TA1 und Q2: TA2 TB2. BOOM! Und genau deswegen nimmt das OS die Sache in die Hand und laesst nur einen nach dem anderen ran. Mit Preemption kann das OS sagen: nu is aber genug mit der Warterei, der naechste kommt bitte an die Reihe.

[Kartenlehrling]

Wurde eigentlich diese Video schon hier geposte?

https://youtu.be/H1L4iLIU9xU?t=253
D3D12 is coming - get ready now! - Unite Europe 2015

[iuno]

https://youtu.be/H1L4iLIU9xU?t=253
Dafür dass ich auf den Link geklickt habe, schuldest du mir jetzt was :P
:facepalm:

Everyone likes standards because you can just program one target and it works everywhere

Low-Level API which you can run everywhere

Also running on consoles [...] and on mobile
Mehr konnte ich mir nicht antun

[Gipsel]

Das Problem ist, dass wenn man eine solche Scheduling Strategie fahren will man immer ein gewisses Resource surplus(Queues, CUs etc.) frei halten muss, das ist aber weder im Interesse des Users, der IHVs oder ISVs.Queues kann man genug einbauen (die neueren AMD-Modelle haben 64 Compute Queues, das dauert zum einen eine Weile, bis dir wirklich voll sind und da kann man auch schon mal die eine oder andere für high priority tasks opfern oder nicht?). Wie funktioniert das eigentlich mit dem von AMD behaupteten Hardware-Support für ihre GPU-Virtualisierung? Da muß im Endeffekt der Command-Prozessor auch irgendwie mit unabhängigen Queues von 15 verschiedenen virtuellen Systemen (die alle mit jeweils einer Instanz des normalen FirePro-Treibers angesteuert werden!), also komplett gekapselten Umgebungen klarkommen. Aber egal.
Wie schon gesagt, muß gar nichts freigehalten werden, da praktisch ständig wieder was frei wird (wenn Waves beendet werden). Du hast doch sicher Profiling-Daten, nicht nur wie lange eine kompletter Drawcall benötigt, sondern z.B. auch eine einzelne Wavefront in sehr langen Drawcalls (Compositing bei einem Renderer mit deferred Shading oder auch ein PP-Pass, wo ein Fullscreen-Quad gerendert wird). Aber machen wir mal eine kurze Milchmädchenrechnung auf, damit die Größenordnungen klar werden:
1080p, also 2 Millionen Pixel ergeben 32k Wavefronts für den Fullscreen-Quad (4k Auflösung wären bereits 128k Wavefronts), wovon auf einer GPU mit 32 CUs mal angenommen 1024 gleichzeitig laufen (32 pro CU oder 8 pro vALU, das ist schon ziemlich großzügig, bei komplexeren Shadern dürften das weniger werden). Die Ausführung dauert insgesamt sagen wir mal 10ms (wäre die Dauer, für die man bei nV nichts Neues absetzen kann). Wie lange dauert jetzt die Ausführung einer Wave? Etwa 300µs. Spätestens dann kann man Wavefronts eines anderen Shaders starten, selbst wenn die komplette GPU total mit dem PP-Pass zu war. Und das ist praktisch Worst Case, typischerweise geht es (teils deutlich) schneller. Wann benötigt eine Wave mal ~300.000 GPU-Takte, um fertig zu werden? Außerdem werden ja meist ständig welche fertig (die bereits seit ein paar oder paar zehn Mikrosekunden laufen).
Ansonsten kann es zu deadlocks kommen wenn ProzessA einen TaskA2 hat welcher auf TaskA1 wartet. Und ProzessB hat einen TaskB2 welcher auf TaskB1 wartet. Der HW Scheduler hat keinen Plan wie die Abhaenigkeiten sind, er nimmt einfach das erste Item in den Queues und wartet ggf. bis eine Semaphore frei wird. Angenommen die HW hat 2 Queues die von beiden Prozessen genutzt wird. Aus Sicht der Applikation ist es vollkommen valide erst T1 und spaeter T2 zu queuen. Und wenn B dabei einfach etwas langsamer als A ist, dann kann das ganze so aussehen: Q1: TB1 TA1 und Q2: TA2 TB2. BOOM! Und genau deswegen nimmt das OS die Sache in die Hand und laesst nur einen nach dem anderen ran. Mit Preemption kann das OS sagen: nu is aber genug mit der Warterei, der naechste kommt bitte an die Reihe.
Zuerst: Wenn TA2 von TA1 und TB2 von TB1 abhängig ist, warum sollte man die überhaupt in verschiedene Queues packen? Ist doch eigentlich Schwachsinn. Die vom Entwickler vorzugsweise zu wählende Variante wäre also TA1 und TA2 in eine Queue und TB1 und TB2 in die andere. Dann laufen TA1 und TB1 parallel und teilen sich die GPU, sobald eine davon fertig ist, rücken die nächsten nach. Fertig ist der Lack.
Aber auch in Deinem (etwas künstlichem) Beispiel gibt es keinen Deadlock. Selbst bei Annahme der strikten in-order-Abarbeitung der Queues (unter OpenCL kann man das prinzipiell durch Setzen von CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE für die Queue ändern, funktioniert bisher aber wohl nur bei Intel) wird es höchstens etwas langsamer, weil der Überlapp geringer oder gar ganz ausfällt. Es wird zuerst TB1 abgearbeitet, TA2 aus der anderen Queue muß wegen der Abhängigkeit von TA1 noch warten. Ist TB1 fertig, startet dann TA1, dann folgt TA2 und schließlich TB2. Nix BOOM, nix Deadlock. Wird vermutlich nur etwas langsamer, weil der Entwickler es deppert auf die Queues verteilt hat und man so nicht von der potentiell höheren Auslastung der GPU durch den Überlapp der Ausführung profitieren kann. Und bei zwei getrennten Prozessen und Kontexten ist das nun wahrlich nicht der "natural fit" ist bzw. gar nicht so einfach. Denn wie mapped das eigentlich auf die Hardware, wenn Prozeß A zwei Queues in Beschlag nimmt, Prozeß B ebenfalls zwei, die Hardware aber 64 hat? Werden dann am Ende nicht 4 in Benutzung sein, womit es so oder so immer mit Überlapp funktioniert?
Und wo genau liegt das Problem, wenn z.B. (von den insgesamt 64 der neueren GCN GPUs oder den 32 bei nV) Compute Queues ein paar wenige für high priority Tasks reserviert bleiben? Bei D3D12 gibt man beim Erstellen einer CommandQueue ja explizit an, ob es eine mit normaler oder hoher Priorität sein soll. Wenn das gut auf die eigentliche Hardware mapped (was eigentlich der Fall sein sollte) und man die so erzeugten high priority Queues nur nutzt, wenn es nötig ist, sehe ich keinen Grund, warum die nicht meist ziemlich leer sein sollten (nur dann funktionieren sie im Sinne des Erfinders).

[Arcanoxer]

Dafür dass ich auf den Link geklickt habe, schuldest du mir jetzt was :P
:facepalm:

Mehr konnte ich mir nicht antun
Der Anfang "DX12 in a Nutshell" ist einfach nur. :ucrazy:
Was hat der bitte geraucht?

[-/\-CruNcher-/\-]

Der Anfang "DX12 in a Nutshell" ist einfach nur. :ucrazy:
Was hat der bitte geraucht?

Ob das vorzeichen dafür sind das Microsoft AMD bald schluckt ? ;)
Schon sehr interessant wie er spezifisch auf die Physikalischen eigenschaft von keinen Queues in DX 11 eingeht im Bezug hier auf Fiji und HBM so dicht am GPU Kern ;)
Denke mal Nvidia kann entspannt sein bis diese Audience da Compute Shader heftig einsetzt wird Pascal Ready sein und den rest kompensiert man bis dahin eben mit dem Software Scheduler so gut wie geht ;)
Und um die Großen Konsolen Publischer kümmert sich bis dahin Nvidias Money Abteilung zusätzlich ;)

[Arcanoxer]

Ob das vorzeichen dafür sind das Microsoft AMD bald schluckt ? ;)HL3 confirmed, SteamOS only. :freak:

[-/\-CruNcher-/\-]

behält sich gabe wohl in der hinterhand die Option ;)

[Hübie]

Was du da aufzählst sind aber eher Defizite im Code, Alphatier, oder versteh ich das falsch? Da kannst auch Raceconditions mit reinnehmen. Hat aber nix mehr mit dem Thema hier zu tun.
Wenn ein Task eine Abhängigkeit hat sollte dieser doch idR sowieso high priority sein, damit dieser in jedem Falle eher fertig ist. Wenn man 64 Ports hat sollte es wohl auch reichen 3 freizuhalten was immer noch 61 ergibt. Oder hast du da konkretere Zahlen aus der Praxis? Wie genau kann man das eigentlich "steuern oder lenken" welche Threadgroups mit den jeweiligen Tasks eher fertig sein müssen wenn man eh eine OoOE hat? Wird das da nicht wieder zerhackstückelt? Ist man dann von der Logik abhängig oder kann man das gezielt beeinflussen (sozusagen am Treiber vorbei wenns nicht in Hardware ist).
Ich stelle übrigens keineswegs deine Kompetenz in Frage, denn immerhin kennen alle hier deine Arbeit ;) Ich kann lediglich nachplappern was ich aus Gesprächen mit Mitarbeitern so aufgeschnappt habe.

[del_4901]

Queues kann man genug einbauen (die neueren AMD-Modelle haben 64 Compute Queues, das dauert zum einen eine Weile, bis dir wirklich voll sind und da kann man auch schon mal die eine oder andere für high priority tasks opfern oder nicht?).
Mit mehr Queues wird das Problem nicht geloest es wird nur unwarscheinlicher und man braucht mehr Prozesse um es zu triggern. Und Murphy lauert in der naechsten Ecke.

Zuerst: Wenn TA2 von TA1 und TB2 von TB1 abhängig ist, warum sollte man die überhaupt in verschiedene Queues packen? Ist doch eigentlich Schwachsinn. Die vom Entwickler vorzugsweise zu wählende Variante wäre also TA1 und TA2 in eine Queue und TB1 und TB2 in die andere. Dann laufen TA1 und TB1 parallel und teilen sich die GPU, sobald eine davon fertig ist, rücken die nächsten nach. Fertig ist der Lack. Weil der Entwickler es so gewollt hat z.B. weil die Tasks async Compute Tasks sind, die mit etwas Anderem parallel laufen sollten.
Aber auch in Deinem (etwas künstlichem) Beispiel gibt es keinen Deadlock. Selbst bei Annahme der strikten in-order-Abarbeitung der Queues (unter OpenCL kann man das prinzipiell durch Setzen von CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE für die Queue ändern, funktioniert bisher aber wohl nur bei Intel) wird es höchstens etwas langsamer, weil der Überlapp geringer oder gar ganz ausfällt. Es wird zuerst TB1 abgearbeitet, TA2 aus der anderen Queue muß wegen der Abhängigkeit von TA1 noch warten. Ist TB1 fertig, startet dann TA1, dann folgt TA2 und schließlich TB2. Nix BOOM, nix Deadlock. Die Queues sind per Definition in Order abzuarbeiten. Ausserdem kann sich das OS nicht auf die Kompetenz der Entwickler verlassen. Und wie gesagt mit mehr Queues oder Ports verschiebt sich das Problem nur zu mehr Prozessen.

[Gipsel]

Mit mehr Queues wird das Problem nicht geloest es wird nur unwarscheinlicher und man braucht mehr Prozesse um es zu triggern. Und Murphy lauert in der naechsten Ecke.Du kannst auch nicht dem OS oder der CPU die Schuld fuer miese Performance geben, wenn Du z.B eine 8 Kern CPU mit 8fach Multithreading hast (also 64 Threads), aber zwei Programme laufen, deren Entwickler es fuer eine gute Idee hielten, ihre Threads hardwired alle auf CPU0 auszufuehren (ich weiss, kein perfektes Beispiel).
Solange da kein Shader in Endlosschleifen festhaengt, gibt es keine Deadlocks.
Weil der Entwickler es so gewollt hat z.B. weil die Tasks async Compute Tasks sind, die mit etwas Anderem parallel laufen sollten.Dann packt er trotzdem nicht voneinander abhaengige Computetasks in unterschiedliche Queues (und auch nicht in die gleichen, wie ein anderer Prozess). Einfache Daumenregeln: Jeder Prozess nutzt fuer nebenlaeufig abzuarbeitende Compute Tasks am besten eigene Queues. Groesstenteils unabhaengige Tasks kommen in unterschiedliche Queues (damit sie parallel ausgefuehrt werden koennen), voneinander abhaengige in die gleiche (das kann natuerlich nicht strikt sein und ueber die Moeglichkeit, unterschiedliche Queues zu synchronisieren, wird die korrekte Ausfuehrung sichergestellt).

Wenn man dann irgendwann 20 Prozesse simultan am Laufen hat, die alle z.B. 4 Compute Queues benutzen wollen (das ist schon eine Menge, finde ich). Dann lauft der Treiber natuerlich in das Problem, dass er verschiedene Software-Queues auf die gleiche Hardware-Queue mappen muss. Das ergibt dann ein Performance Problem (hat man das nicht sowieso bei 20 Prozessen, die gleichzeitig versuchen ordentlich Compute-Last abzusetzen?). Wenn Du auf einer Quadcore-CPU zehn Instanzen eines Renderes gleichzeitig anwirfst, wird es auch nicht mehr unbedingt schnell sein. Aber Deadlocks gibt es trotzdem nicht.

Die Queues sind per Definition in Order abzuarbeiten.Das stimmt zumindest fuer OpenCL schon mal nicht, da kann man explizit die OoO-Abarbeitung fuer eine Queue erlauben. Bei D3D12 habe ich ehrlich gesagt nicht so viel Ahnung von, aber ein kurzer Blick in die Doku sieht fuer mich so aus, als wenn MS sich da vielleicht ein Hintertuerchen fuer den einen oder anderen Spezialfall offengelassen hat:
In D3D12 the concept of a command queue is the API representation of a roughly serial sequence of work submitted by the application. Barriers and other techniques allow this work to be executed in a pipeline or out of order, but the application only sees a single completion timeline.
Ausserdem kann sich das OS nicht auf die Kompetenz der Entwickler verlassen. Und wie gesagt mit mehr Queues oder Ports verschiebt sich das Problem nur zu mehr Prozessen.Fuer gute Performance muss man sich sowieso auf die Entwickler verlassen. Und ausserhalb von wirklichen Bugs ist die korrekte Ausfuehrung sichergestellt. Erlaubt man noch, dass verschiedene Kontexte in einer Queue OoO abgearbeitet werden koennen (also Multitasking aehnlich wie auf einer CPU: Dispatch von ein paar Wavefronts von einem Kontext, dann ein paar vom naechsten usw. also "Preemption" im Command-Prozessor/der Queue*) wird es auch noch fuer sehr viele Software-Queues (>Anzahl der Hardware-Queues) ganz gut vorhersagbar. Aber gegen endlos loopende Wavefronts hilft das auch nicht, da braeuchte man "echte" Preemption der laufenden Waves (es koennen nur neue Waves abgesetzt werden, wenn genuegend Resourcen im Shaderarray der GPU dafuer frei sind). Und dafuer ist die Not vermutlich bisher noch nicht gross genug.

*):
AMDs neueren ACEs arbeiten im Prinzip bereits so. Jede ACE verwaltet 8 Queues. Davon kann aber zu jedem Zeitpunkt immer nur von einer einzigen eine neue Wavefront abgesetzt werden. Allerdings wechselt der Dispatch je nach Prioritaetssettings schnell zwischen den verschiedenen Queues einer ACE (wenn mehrere Tasks bereit sind). Der eigentliche Commandbuffer liegt ja sowieso im von der GPU adressierbaren RAM. Ganz doll heruntergekocht stellt so eine Queue ja nicht viel mehr dar als ein paar Pointer auf Strukturen mit den noetigen Verwaltungsinformationen und dem eigentlichen Commandbuffer (bzw. der Liste davon) in der Queue (wobei ein paar Dinge natuerlich der Performance wegen onchip gehalten werden). Da eine Queue gegen eine andere auzutauschen, sollte hardwaretechnisch nicht das ganz grosse Problem darstellen und eine ueberschaubare Erweiterung der bisherigen Moeglichkeiten sein.

[Jupiter]

Ich habe keine Ahnung was das zu bedeuten hat.

NVIDIA Will Fully Implement Async Compute Via Driver Support, Oxide Confirms: http://www.dsogaming.com/news/nvidia-will-fully-implement-async-compute-via-driver-support-oxide-confirms/

[-/\-CruNcher-/\-]

Ich habe keine Ahnung was das zu bedeuten hat.

NVIDIA Will Fully Implement Async Compute Via Driver Support, Oxide Confirms: http://www.dsogaming.com/news/nvidia-will-fully-implement-async-compute-via-driver-support-oxide-confirms/

Sie optimieren das Scheduling im Treiber zu lasten von Cpu Cycles, es wird interessant zu sehen wo Nvidia rauskommt Performance/Consumption und auch Latency im overall :)

[Gipsel]

Ich habe keine Ahnung was das zu bedeuten hat.

NVIDIA Will Fully Implement Async Compute Via Driver Support, Oxide Confirms: http://www.dsogaming.com/news/nvidia-will-fully-implement-async-compute-via-driver-support-oxide-confirms/
Diese ueber Oxide transportierte Aussage von nV kennen wir schon. Ansonsten wirft der Artikel selber (bzw. der zitierte "Mahigan") etwas viel durcheinander (Warp Scheduler [vermutlich irrelavant in dem Kontext, solange nV das Mischen von Shadern aus verschiedenen Kontexten auf einem SMM erlaubt; bei AMD redet ja auch niemand von den Instruction Buffern und Schedulern der CUs selber], Shader Engine, SMM, Grid Management Queue, ...), um das wirklich ernst zu nehmen. Und ich bezweifle auch nicht nur ein wenig, dass nV die Work Distribution an die einzelnen Warp Scheduler in Software auf der CPU im Treiber macht. Software-Intervention fuer jeden Warp mit 32 Fragments/Vertices/whatever mitsamt Resource-Tracking in den Shadern? Niemals. Da werden maximal eine Handvoll Regeln definiert und dann macht das die GPU schon selber.

[Novum]

Hatte den selben Eindruck, ergibt keinen Sinn was dort steht.

[-/\-CruNcher-/\-]

@Gipsel

Was schätzt du den ein wieviel Performance Nvidias Engineers hier noch rausholen werden können bzw wie weit sie trotzdem hinter GCN liegen werden ?
Immerhin impliziert ihre transportierte Aussage das sie die Performance hier steigern werden per Treiber, sowas sag ich nicht einfach so da weiss ich anhand des Code Reviews von Oxide ja das ich es auch kann ;)

Sie müssen jetzt ja Ergebnise liefern so wie damals bei Tomb Raider 2013 und TressFX.

Natürlich bleibt der Nachgeschmak eines Perfekt inszenierten Marketing Stunts Nvidias (absichtlich die Performance zu sabotieren um später wieder als die Könige da zu stehen wie Huddy ja meint das sie es immer tun) ;)

Schlechte News die sich dann umdrehen während mein Competitor auf den Zug aufspringt mich versucht zu diskreditieren ist verdammt evil vielleicht hat Huddy recht da hätte er seine Kollegen aber lieber warnen sollen :D

[Gipsel]

@Gipsel

Was schätzt du den ein wieviel Performance Nvidias Engineers hier noch rausholen werden können bzw wie weit sie trotzdem hinter GCN liegen werden ?
Immerhin impliziert ihre transportierte Aussage das sie die Performance hier steigern werden per Treiber, sowas sag ich nicht einfach so da weiss ich anhand des Code Reviews von Oxide ja das ich es auch kann ;)

Sie müssen jetzt ja Ergebnise liefern so wie damals bei Tomb Raider 2013 und TressFX.

Natürlich bliebt der Nachgeschmak eines Perfekt inszenierten Marketing Stunts Nvidias (absichtlich die Performance zu sabotieren um später wieder als die Könige da zu stehen wie Huddy ja meint das sie es immer tun) ;)Keine Ahnung. Nachdem, was nV offiziell ueber HyperQ (nVs Version der ACEs) gesagt hat, sollte es eigentlich spaetestens mit Maxwell v2 in etwa genau so funktionieren wie bei AMD (vielleicht abzueglich der Moeglichkeit, ueber die 3D-Queue abgesetzte Compute-Tasks asynchron zu "wirklichen" Grafik-Tasks abzuarbeiten; der Grafik-Commandprozessor bei AMD hat dazu eine zusaetzliche parallele Compute Pipe). Aber ich habe ja schon oefter zum Ausdruck gebracht, dass man den schoenen Praesentationen von nV fuer die Oeffentlichkeit bei technischen Details nicht immer ganz vertrauen kann, da dort die PR-Abteilung manchmal genauso viel zu sagen haben scheint, wie die Ingenieure.
Und nach dem, was nV zu VR bei der diesjaehrigen GDC gesagt hatte, koennen sie anscheinend Compute-Kernel doch nur zwischen Drawcalls schieben und nicht simultan zum Dispatch bringen. Keine Ahnung warum (denkbar ware ja eigentlich nach der Darstellung dort nur eine Hardwareeinschraenkung bei der Verarbeitung von Grafik und Compute, so dass nicht zwei Kontexte gleichzeitig aktiv sein koennen [eben nur mehrere Compute-Kontexte, aber nicht Grafik+Compute]) oder ob das ein Fehler in der Praesentation war (waere aber ein heftiger gewesen). Wenn es nur ein Problem mit mehreren gleichzeitigen Grafik-Kontexten gaebe (also Grafik+Compute gehen wuerde), haetten die doch bestimmt gesagt, man solle den eingeschobenen high priority Async-Timewarp bei VR mit einem Compute-Shader machen und nicht, dass man die Drawcalls kurz (moeglichst unter einer Millisekunde) halten muss, damit man das reinquetschen kann.

[aufkrawall]

Kann bei DX12 der Treiber eigentlich noch bestimmen, wie viele Frames voraus gerendert wird?
Es sollen ja zumindest auf CPU-Seite weniger Tricks möglich sein, wie etwa das Auslagern des Overheads in einen gesonderten Thread per Treiber.

[-/\-CruNcher-/\-]

Ah ok Nathan Reed erklärt es ja screen space tiles nutzen um das Problem zu umgehen um unter die 1ms zu kommen so das die Preemption über den Nvapi High pririory Context einsetzen kann, das ist tatsächlich eine Limitierung.

[Novum]

Kann bei DX12 der Treiber eigentlich noch bestimmen, wie viele Frames voraus gerendert wird?
Da die Applikation selber synchronisieren muss, ob und was von vorherigen Frames fertig ist, ist die Antwort wahrscheinlich nein.

Es sollen ja zumindest auf CPU-Seite weniger Tricks möglich sein, wie etwa das Auslagern des Overheads in einen gesonderten Thread per Treiber.
Das wäre theoretisch immer noch möglich, aber Sinn ergeben tut es nicht. Man hat ja mehrere Producer auf Applikations-Seite mit DX12 in den meisten Fällen, man müsste also auch mehrere Treiber-Threads erzeugen und der Treiber weiß nichts davon wie die Applikation programmiert ist.

Ich gehe stark davon aus, dass die Treiber das nicht standardmäßig tun werden. Wenn überhaupt dann werden einzelne Applikationen "optimiert".

[aufkrawall]

Thx for sharing.

Da die Applikation selber synchronisieren muss, ob und was von vorherigen Frames fertig ist, ist die Antwort wahrscheinlich nein.

Das wäre zwar einerseits schlecht, andererseits hätte NV damit keinen Vorteil mehr bez. Input Lag bei modernen Spielen. Damit ist AMD hoffentlich wieder angesagter für kompetitive Spiele.

Hoffentlich gehört dann zum Paradigmenwechsel auch, dass die Entwickler selber nicht mehr vorausrendern. Scheint zumindest bei DX11 häufig komplett hirnrissig zu sein.

[samm]

Es wäre nur dann schlecht, wenn die Devs von kompetitiven Online-Spielen (va. Shooter) nicht fix auf 0 bis 1 prerendered hinprogrammieren würden. Und dann wären die Engine-Devs schuld, dass sie an den Anforderungen des eigenen Genres vorbeientwickeln.Scheint zumindest bei DX11 häufig komplett hirnrissig zu sein.Agree. Denke diesbezüglich auch an den beschissenen Ersatz für triple buffering.

[aufkrawall]

Das hat mit Vsync erstmal gar nichts zu tun, das müssen verschiedene Queues sein (du hast bei NV weiterhin "TB" Vsync, wenn du prerenderlimit 1 per Treiber festlegst).
Selbst bei RTS-Spielen oder Mobas mit Windows-Cursor nervt prerendern während des Klickens oder des Verschiebens der Kamera.
Engine-Entwickler müssen das so hinbekommen, dass es auch ohne Prerender keine nennenswerten Performance-Einbußen gibt. Alles andere ist einfach nur Fail.
Ein paar % weniger Performance kann es nicht wert sein, ein oder gar mehrere Frames zusätzlich auf den Input warten zu müssen.

[samm]

Das hat mit Vsync erstmal gar nichts zu tun, das müssen verschiedene Queues seinSo meinte ich das auch nicht. Idee war: ein weiteres Beispiel, wie Queues in aktuellen Engines auf schlechte Art genutzt werden.

[dargo]

Engine-Entwickler müssen das so hinbekommen, dass es auch ohne Prerender keine nennenswerten Performance-Einbußen gibt. Alles andere ist einfach nur Fail.

Ich verstehe ehrlich gesagt nicht warum Prerenderlimit nicht jeder Entwickler in sein Spiel intergriert? Schließlich schafft das Ubisoft @Watch Dogs ja auch.

[Blediator16]

Wenn man die Arbeit auf die CPU abwälzen kann, dann sieht das mit der GPU Effizient natürlich besser aus. Coole Taktik eigentlich :D

[Hübie]

Gut das computerbase.de die Leistungsaufnahme des gesamten Systems misst ;) Können die hater weniger haten.

@Gipsel: HyperQ war doch auch damals schon in Software gelöst oder etwa nicht? :|

[Blediator16]

Gut das computerbase.de die Leistungsaufnahme des gesamten Systems misst ;) Können die hater weniger haten.

@Gipsel: HyperQ war doch auch damals schon in Software gelöst oder etwa nicht? :|

Ach es wurde bereits mit dem Async Spezial Treiber gebencht?:D

[Hübie]

Und das steht genau wo in meiner Aussage? Meinst du dass die CPU plötzlich explosionsartig mehr verbrauchen wird? :rolleyes:

[Gipsel]

@Gipsel: HyperQ war doch auch damals schon in Software gelöst oder etwa nicht? :|Laut nV eigentlich nicht. Die sollen da mehrere Queues in Hardware haben, die simultan Warps an das Shaderarray dispatchen koennen.

[Hübie]

Hm. Und das wurde mit Maxwell wieder verworfen und dann in Software gelöst? War vielleicht zu ineffizient? Müsste ja schon breit angebunden sein, oder meinst da ist pro GPC ein dispatcher separat integriert? Ich hasse nVidia diesbezüglich. Den s. g. whitepapern kann man nix richtig entnehmen...

[Nakai]

Hm. Und das wurde mit Maxwell wieder verworfen und dann in Software gelöst? War vielleicht zu ineffizient? Müsste ja schon breit angebunden sein, oder meinst da ist pro GPC ein dispatcher separat integriert? Ich hasse nVidia diesbezüglich. Den s. g. whitepapern kann man nix richtig entnehmen...

HyperQ hatte doch nur GK110 und GK208 bei Kepler, afaik.

Ahja ab CC3.5 sollte HyperQ ünterstützt werden, ergo haben es alle Maxwells.

€: Forum: https://devtalk.nvidia.com/default/topic/786896/is-hyperq-supported-in-gtx-750-ti-/?ClickID=bmkguzzmndnms66fzdeqmgmgem1fvdeyggyg

€2: Keine Ahnung wie das genau eingebaut ist...Software oder Hardware nvm.

[Hübie]

Das ist mir klar. Ich erinnere mich an einen guten Artikel vom Konrad Zuse Institut in Berlin mit dem GK110. So etwas wünsche ich mir mit Maxwell ;)
Afaik wird das queueing auf den Maxwell GPCs in Software vom Compiler festgelegt, was wiederum auf der CPU statt findet.
Bin jetzt aber zu müde um zu denken. Gn8 :smile:

[fondness]

“You will find that the vast majority of DX12 titles in 2015/2016 are partnering with AMD. Mantle taught the development world how to work with a low-level API, the consoles use AMD and low-level APIs, and now those seeds are bearing fruit.”

https://www.reddit.com/r/AdvancedMicroDevices/comments/3iwn74/kollock_oxide_games_made_a_post_discussing_dx12/

http://s9.postimg.org/g75l5jrxr/AMD_DX12_635x198.jpg (http://postimage.org/)

Mittlerweile kann man auf jeden Fall auch noch Rise of Tomb Raider ergänzen.

[Hübie]

Ja das Spiel wird ein richtig guter Kracher. Freu mich auf die genannten Titel und bin gespannt wie sich das Performance-Bild zeichnet.

Ich habe glaub ich beim CUDA SDK ein sample für HyperQ gesehen. Da ich meinen Rechner heute umbaue müsste mal jemand anderes mit Maxwell bitte schauen ob man daraus was ablesen kann. Eine K20x braucht 0,021 Sekunden für das Laden und Rechnen. GTX 680 0,337 Sekunden (hat kein HyperQ).

Edit: Takt muss dann angepasst werden.

[M4xw0lf]

https://www.reddit.com/r/AdvancedMicroDevices/comments/3iwn74/kollock_oxide_games_made_a_post_discussing_dx12/

http://s9.postimg.org/g75l5jrxr/AMD_DX12_635x198.jpg (http://postimage.org/)

Mittlerweile kann man auf jeden Fall auch noch Rise of Tomb Raider ergänzen.
Pff, vast majority wird abzuwarten sein. Ich denke Nvidia und die Nvidia-Monies werden da noch ein Wörtchen mitzureden haben.

[deekey777]

https://www.reddit.com/r/AdvancedMicroDevices/comments/3iwn74/kollock_oxide_games_made_a_post_discussing_dx12/

http://s9.postimg.org/g75l5jrxr/AMD_DX12_635x198.jpg (http://postimage.org/)

Mittlerweile kann man auf jeden Fall auch noch Rise of Tomb Raider ergänzen.
Die Frage ist, welches Logo auf DX12-Spielen zu sehen sein wird. Bei mindestens 3 wird man das AMD-Logo sehen.

Die Entwickler wollten doch low-level-APIs? Dann dürfen sie jetzt über die negativen Konsequenzen (mehr Arbeit durch weniger Abstraktion) ihrer Forderung nicht meckern. Das wäre ja lächerlich.

Oder verstehe ich dich falsch?
Diese Entwickler waren wer? DICE in erster Linie, dann Epic, Crytek? Das sind keine armen Schlucker, sie können es sich leisten, insbesondere wenn sie noch Geld bekommen bzw. ihnen Arbeit abgenommen wird, wenn auf ihren Spielen das eine oder andere Logo gezeigt wird.

Die meisten bleiben bei DX11: Eine API für Windows 7, Windows 8 und Windows 10. Selbst Vista unterstützt DirectX 11. Mit DirectX 11 werden alle Radeons ab HD5000 unterstützt, was bei DX12 nicht der Fall ist. Wenn AMD DX12 pusht, dann auch Leute zum Umstieg zu bewegen.

Für Besitzer einer HD5000/HD6000 wäre es wirklich genial, wenn Spiele unter Windows 10 nur DX12 bieten.

[Gipsel]

Afaik wird das queueing auf den Maxwell GPCs in Software vom Compiler festgelegt, was wiederum auf der CPU statt findet.Der Compiler stellt nur fest, welche Instruktionen unabhaengig voneinander sind und fuer dual issue in Frage kommen. Das ist auf einer anderen Ebene als das Queueing von Tasks. Damit hat der Compiler ueberhaupt nichts zu tun. Der kann doch nicht mal theoretisch wissen, fuer wie viele Warps der Code ausgefuehrt wird (der wird einmal kompiliert, aber doch meist sehr oft ausgefuehrt), noch was sonst so auf der GPU ausgefuehrt werden will.

[dargo]

Diese Entwickler waren wer? DICE in erster Linie, dann Epic, Crytek? Das sind keine armen Schlucker, sie können es sich leisten, insbesondere wenn sie noch Geld bekommen bzw. ihnen Arbeit abgenommen wird, wenn auf ihren Spielen das eine oder andere Logo gezeigt wird.

Die meisten bleiben bei DX11

Wer ist die meisten? Alle AAA-Produktionen werden auf DX12 gehen, ich sehe da keinen Grund es nicht zu unterstützen.


Eine API für Windows 7, Windows 8 und Windows 10. Selbst Vista unterstützt DirectX 11.

Windows Vista interessiert heute keine Sau mehr.
http://store.steampowered.com/hwsurvey/directx/

[deekey777]

Die meisten Entwickler = AAA-Studios. Wieder was gelernt.

Das Geld liegt ja schließlich einfach rum.

[dargo]

Die meisten Entwickler = AAA-Studios. Wieder was gelernt.

Das Geld liegt ja schließlich einfach rum.
Immer der gleiche Blödsinn.

Hast du den gesamten Übergang von DX9 auf DX10/11 verschlafen? Auch mal daran gedacht, dass du mit DX12 dank deutlich effizienteren Nutzung der Hardware auch mehr Spieler erreichst?


Für Besitzer einer HD5000/HD6000 wäre es wirklich genial, wenn Spiele unter Windows 10 nur DX12 bieten.
Wieso nur? Wer sagt, dass alles was mit DX12 kommt keinen DX11 Renderpfad beim Übergang hat? Die HD5xxx Serie gibt es mittlerweile seit 6 Jahren. Damit kann du heute eh keinen AAA-Titel in Full-HD (das ist die Auflösung die mittlerweile beim Mainstream angekommen ist) vernünftig spielen. Irgendwann muss man sich mal von der alten Hardware trennen. 6-8 Jahre ist auch ungefähr die Lebenserwartung einer Konsole.

[Kartenlehrling]

Was ist eigentlich aus dem DX12 patch für ARK:Survival Evolved geworden?


Ahh ja ...

[08/28/15] ARK DirectX 12 Delay
ARK DirectX 12 Delay

Hello Survivors,

It's been a long week here at Studio Wildcard as the programming team has been grinding to get the DX12 version ready for release.
It runs, it looks good, but unfortunately we came across some driver issues that we can't entirely tackle ourselves :(.

We’ve reached out to both NVIDIA and AMD and will be working with them to get it resolved as soon as possible! Once that’s tackled,
we’ll be needing to do more solid testing across a range of hardware with the new fixes.
Sadly, we're gonna have to delay its release until some day next week in order to be satisfied with it.
It's disappointing to us too and we're sorry for the delay,
really thought we’d have it nailed today but we wouldn't want to release ARK DX12 without the care it still needs at this point.
Hang in there, and when it's ready for public consumption, it should be worth the wait!
https://steamcommunity.com/app/346110/discussions/0/520518053440119300/

[d2kx]

Dass hier überhaupt über DX12 Exklusivität diskutiert wird... mindestens DX11 wird es selbstverständlich noch eine sehr lange Zeit als Fallback in sämtlichen, kommenden Titeln geben.

[deekey777]

Dass hier überhaupt über DX12 Exklusivität diskutiert wird... mindestens DX11 wird es selbstverständlich noch eine sehr lange Zeit als Fallback in sämtlichen, kommenden Titeln geben.
DX12 = Windows 10. Von welcher Exklusivität muss da noch geredet werden.

[Locuza]

Naja mit DX11 schließt man noch ältere Betriebssysteme mit ein und ein paar ältere Chips.
Ivy-Bridge, VLIW4/5 Ableger (Die APUs sind noch nicht ganz so alt).

[-/\-CruNcher-/\-]

OS Agnostisch zu sein ist immer ein Vorteil und wenn Khronos es diesmal richtig macht könnte Vulkan sehr erfolgreich werden :)
Wobei OS Agnostisch so nicht korrekt ist man muss das OS sehr genau mit in die API einbeziehen und bei Vulkan hat man seine Hausaufgaben über NT 6+ allem anschein sehr ordentlich gemacht diesmal ;)

[d2kx]

DX12 = Windows 10. Von welcher Exklusivität muss da noch geredet werden.

Das meinte ich nicht. Es ging mir darum, dass einige Mitglieder glauben, dass es in absehbarer Zeit Titel geben wird, die *ausschließlich* mit Win10/DX12 laufen werden.

[deekey777]

Das meinte ich nicht. Es ging mir darum, dass einige Mitglieder glauben, dass es in absehbarer Zeit Titel geben wird, die *ausschließlich* mit Win10/DX12 laufen werden.
Es wird solche Titel geben. Aber in den ersten paar Jahren wird man dafür weniger als fünf Finger brauchen, um sie zu zählen.

Microsoft wird definitiv mehrere Titel bringen, die ohne Sinn und Verstand Window 10 exklusiv sein werden, dafür reicht das Angebot über den Store mit entsprechendem Flag aus.

[Kartenlehrling]

Wie funktionieren eigentlich die OnScreenDisplay, bei Mantle gab es ja nie wirklich Unterstützung, haben sich die Entwickler von Afterburner&Co. bei DX12 für unterstützt bemüht?
Ich finde da keine Infos kann man zb. Ashes of the Singularity mit Afterburner+HWinfo64 betreiben?

[Unicous]

Ich bin mir ziemlich sicher, dass die OSDs einfach neu geschrieben werden müssten und die Entwickler im Fall von Mantle entweder keinen Bock oder keinen Zugang hatten. Iirc hat doch z.B. Valve auch etwas bei Steam gemacht um das Overlay anzeigen zu können und bei diesem Raptr Zeugs war es ähnlich.

[aufkrawall]

EVGA Precision X unterstützt es schon seit einiger Zeit afair.
Habs aber noch nicht getestet. Die fps-Anzeige von GeForce Experience funktioniert auch (sowie ShadowPlay).

[Demirug]

Ich bin mir ziemlich sicher, dass die OSDs einfach neu geschrieben werden müssten und die Entwickler im Fall von Mantle entweder keinen Bock oder keinen Zugang hatten. Iirc hat doch z.B. Valve auch etwas bei Steam gemacht um das Overlay anzeigen zu können und bei diesem Raptr Zeugs war es ähnlich.

Wenn die Funktion nicht irgendwo unten im Treiber selbst ist muss es für jedes API neu geschrieben werden. Das Problem bei Mantle war tatsächlich das fehlende öffentliche SDK. Da Leute die solche Tools mehr oder weniger in ihrer Freizeit schreiben haben selten Lust dazu haben auch noch bei einem IHV betteln zu gehen.

[AnnoDADDY]

Das meinte ich nicht. Es ging mir darum, dass einige Mitglieder glauben, dass es in absehbarer Zeit Titel geben wird, die *ausschließlich* mit Win10/DX12 laufen werden.

wieso sollte das nicht geschehen? win10 hat wohl schon nen höheren marktanteil oder zumindest gleichwertig zu win7 und ist derzeit kostenlos, sodass wahrscheinlich ende des jahres schon wenigstens 50% marktanteil drinne sein können, früher hat das die entwickler doch auch nicht gestört für das neueste allein zu entwickeln, ich sehe derzeit keine bremsen für dx12/win10 only

[dargo]

wieso sollte das nicht geschehen? win10 hat wohl schon nen höheren marktanteil oder zumindest gleichwertig zu win7...

Na... wir wollen nicht gleich übertreiben. Windows 7 liegt bei Steam noch bei ~50%.
http://store.steampowered.com/hwsurvey/directx/

Darauf stützen sich auch einige Publisher. Schauen wir erstmal wo Windows 10 Ende 2015 steht. Ich prophezeihe mal 25-30%. Wer bietet mit? :D

PS: gibt es mittlerweile auch so eine Hardware-Auswertung bei Origin und uPlay?

[d2kx]

Na... wir wollen nicht gleich übertreiben. Windows 7 liegt bei Steam noch bei ~50%.
http://store.steampowered.com/hwsurvey/directx/

Darauf stützen sich auch einige Publisher. Schauen wir erstmal wo Windows 10 Ende 2015 steht. Ich prophezeihe mal 25-30%. Wer bietet mit? :D

Könnte hinkommen. Ich hoffe die User hier vergessen nicht, dass es in Asien viele, viele Spieler gibt, die hauptsächlich in Internet Cafes spielen, welche teilweise noch mit Windows XP oder Vista betrieben werden.

Übrigens, wo wir gerade beim Thema sind. Valve wird demnächst den DX9-Pfad aus der Source Engine 2 entfernen und erstmals offiziell und ohne eigenständiges Eingreifen OpenGL (~4.1) als Option für Windows anbieten, angefangen mit DotA 2. Sie überlegen außerdem, den DX11-Pfad zu entfernen, falls es mit dem OpenGL-Pfad keine unerwarteten Probleme gibt.

Im Dezember kommt dann natürlich noch Unterstützung für Vulkan hinzu, bzw. die ist jetzt schon gegeben, es fehlen nur die öffentlichen Treiber.

[aufkrawall]

Könnte hinkommen. Ich hoffe die User hier vergessen nicht, dass es in Asien viele, viele Spieler gibt, die hauptsächlich in Internet Cafes spielen, welche teilweise noch mit Windows XP oder Vista betrieben werden.

Das ist keine zahlende Käuferschaft für AAA-Vollpreisspiele.


Übrigens, wo wir gerade beim Thema sind. Valve wird demnächst den DX9-Pfad aus der Source Engine 2 entfernen und erstmals offiziell und ohne eigenständiges Eingreifen OpenGL (~4.1) als Option für Windows anbieten, angefangen mit DotA 2. Sie überlegen außerdem, den DX11-Pfad zu entfernen, falls es mit dem OpenGL-Pfad keine unerwarteten Probleme gibt.

Find ich gut. Aber nur, wenn nicht mit neuen Treiberversionen ständig etwas kaputt geht.

[Hübie]

Der Compiler stellt nur fest, welche Instruktionen unabhaengig voneinander sind und fuer dual issue in Frage kommen. Das ist auf einer anderen Ebene als das Queueing von Tasks. Damit hat der Compiler ueberhaupt nichts zu tun. Der kann doch nicht mal theoretisch wissen, fuer wie viele Warps der Code ausgefuehrt wird (der wird einmal kompiliert, aber doch meist sehr oft ausgefuehrt), noch was sonst so auf der GPU ausgefuehrt werden will.

Hm. Jetzt ergibt das Sinn. Gestern Abend sah das anders aus =)

[][immy]

Kleine Frage am Rande.
Wenn NVidia Probleme mit async Compute haben sollte, könnte man diese Compute jobs nicht über igpu laufen lassen. Das sind immerhin ressourcen die inzwischen fast jeder Rechner besitzt aber besonders Spiele PC fast überhaupt nicht nutzen.

[Hübie]

Wenn es Effekte fürs PostProcessing sind, theoretisch ja. Aber die großen haben alle keine iGPU ;) Also benachteiligt man die highend user.

[Birdman]

Übrigens, wo wir gerade beim Thema sind. Valve wird demnächst den DX9-Pfad aus der Source Engine 2 entfernen und erstmals offiziell und ohne eigenständiges Eingreifen OpenGL (~4.1) als Option für Windows anbieten, angefangen mit DotA 2. Sie überlegen außerdem, den DX11-Pfad zu entfernen, falls es mit dem OpenGL-Pfad keine unerwarteten Probleme gibt.

Taugt der (openGL Pfad) denn was mit den Karten/Treibern der aktuellen Hersteller?
nVidia gehe ich stark davon aus, aber AMD und Intel? Gab ja seit Jahren keinen AAA Titel mehr der OpenGL voraussetzte, daher war es auch ziemlich wayne was die Treiber in dieser Disziplin leisten konnten...

[Guest83]

Übrigens, wo wir gerade beim Thema sind. Valve wird demnächst den DX9-Pfad aus der Source Engine 2 entfernen und erstmals offiziell und ohne eigenständiges Eingreifen OpenGL (~4.1) als Option für Windows anbieten, angefangen mit DotA 2. Sie überlegen außerdem, den DX11-Pfad zu entfernen, falls es mit dem OpenGL-Pfad keine unerwarteten Probleme gibt.
Woher hast du das?

Ich hab vor ein paar Monaten mal bei Valve nachgefragt ob sie künftig voll auf Vulkan (auf Windows) setzen werden und deshalb auf D3D12 verzichten. Die Antwort die ich bekommen hab deutete durchaus darauf hin: It’s too early to say definitively what we’ll use on Windows long term. Obviously, a Vulkan-only approach would be preferable since it means supporting fewer rendering backends in Source 2.

[Lord_X]

Woher hast du das?

Ich hab vor ein paar Monaten mal bei Valve nachgefragt ob sie künftig voll auf Vulkan (auf Windows) setzen werden und deshalb auf D3D12 verzichten. Die Antwort die ich bekommen hab deutete durchaus darauf hin: It’s too early to say definitively what we’ll use on Windows long term. Obviously, a Vulkan-only approach would be preferable since it means supporting fewer rendering backends in Source 2.
Ich denke du musst das als ersten Schritt sehen. (Valve will D3D_X einfach los werden, Vielleicht Wartungsaufwand?) Erst wenn Vulkan "final" ist, wird die Reise dorthin gehen. Dann kann aber noch ein bisschen dauern.

[Skysnake]

Valve wird es vor allem loswerden wollen, damit Sie sich nicht mit dem Windows App-Store rumschlagen müssen. Wer unterstützt schon gern die Konkurrenz?

[deekey777]

Ich denke du musst das als ersten Schritt sehen. (Valve will D3D_X einfach los werden, Vielleicht Wartungsaufwand?) Erst wenn Vulkan "final" ist, wird die Reise dorthin gehen. Dann kann aber noch ein bisschen dauern.
Warum soll er die Aussage als ersten Schritt sehen, wenn die Behauptung, auf die er sich bezieht, so ziemlich absolut ist?

[Hübie]

Valve wird es vor allem loswerden wollen, damit Sie sich nicht mit dem Windows App-Store rumschlagen müssen. Wer unterstützt schon gern die Konkurrenz?

Wo ist denn da der Zusammenhang? D3D12-Titel müssen nicht über den Store angeboten werden. Oder hab ich dich missverstanden?

[Skysnake]

Sie müssen es noch nicht, aber darum geht es nicht. DX12=Win10 Win10=Store -> DX12=Store ;)

Mit jedem DX12 Spiel pusht man so indirekt also auch den Windows Store. Auf der anderen Seite könnte man mit Vulcan und einem abartig guten HL3 Linux pushen und Lunix != Windows Store ;)

Vielleicht ist das zu weit gedacht, aber ich seh da schon Kalkül bezüglich einem Kampf der Vertriebswege.

[Lord_X]

Warum soll er die Aussage als ersten Schritt sehen
Weil Vulkan noch nicht fertig ist?

[DinosaurusRex]

Ich glaube Valve bereitet sich eher auf eine Cloud Gaming-Zukunft vor, in der Spiele nicht mehr verkauft werden, sondern nur noch als temporärer Service angeboten werden. Mal angenommen Microsoft fängt in einigen Jahren an, mit den Marktanteilen von Win10 (oder Nachfolger) + X1 (oder Nachfolger) [wird sowieso ein und das Selbe sein] zu argumentieren und gibt den Publishern die Möglichkeit, die Azure-Ressourcen für Cloud Gaming anzuzapfen. Dann wäre Valve richtig am Arsch.

Derzeit geht es für alle um Marktanteile. Wie wichtig sowas ist, sieht man alleine an Spotify: Sony Music, eines der größten Labels der Welt, das direkt an der Quelle sitzt, hatte keine Chance trotz PS4-Erfolg gegen Spotify anzukommen. Selbst Apple beißt sich an denen trotz unvergleichlicher Hardware-Verkäufen die Zähne aus. Du musst deine Schäfchen rechtzeitig im Trockenen haben. Gegen Netflix hat auch kaum noch jemand eine Chance. Das Resultat sind Zusammenarbeiten verschiedener Medienunternehmen und Plattforminhaber, wie zB der Exklusiv-Deal von SCE und Spotify mit dem bescheuerten Namen "PlayStation presents Spotify" (und da bin ich vor allem auf Nintendo gespannt, die einen katastrophalen Fehlstart hingelegt haben).

Valve ist derzeit nur eine Storefront, die auf den guten Willen derjeniger angewiesen ist, die den PC-Markt kontrollieren und der Sheriff in der Stadt ist nunmal zweifellos Microsoft. Microsoft wird das Wasser, in dem Valve sitzt, immer weiter zum Kochen bringen und Gabe Newell ist kein Idiot. Der weiß, dass sich Valve von Windows emanzipieren muss, wenn es im Cloud Gaming-Zeitalter noch eine Rolle spielen will.

Das ist im Kern auch schon der Grund für die ganze "Konsolifizierung", die der PC mit Valve derzeit durchmacht und auch zukünftig durchmachen wird: Kleine Formfaktoren, "Living Room Experience", Gamepads, kein All-in-One mehr, das ist so gar nicht typisch PC, aber es ist nötig, um in der Gaming-Welt neben Microsoft, PlayStation, Android und iOS (und dem was Nintendo vorhat) zu bestehen. Diese Unternehmen haben alle ihre eigenen Plattformen, in denen sie die Regeln machen. Valve hat das nicht. Das wollen sie mit SteamOS ändern.

Amazon hab ich ganz vergessen! Die werden auch eine Rolle spielen. Facebook wird bestimmt auch noch mitreden.

[dargo]

Ich glaube Valve bereitet sich eher auf eine Cloud Gaming-Zukunft vor, in der Spiele nicht mehr verkauft werden, sondern nur noch als temporärer Service angeboten werden.
Davon sind wir noch einige Jahrzehnte entfernt. Die Latenzen sind einfach tödlich. Cloud ist heute für eine einzige Sache sinnvoll... Savegames.

[robbitop]

Den meisten Heiopeis dürfte das, wie auch schlechterer Auflösung wenig ausmachen. Ob es 10 ms lag oder 100 ms ist, merken viele nicht. Insbesondere, wenn man mit Gamepad am TV spielt.
Mit einer PS4 kannst du schon per Remote aus dem Store spiele per Remote spielen. Das geht schon relativ ok. Eine brauchbare Internetverbindung vorausgesetzt - die ja immer besser wird.

Für uns Enthusiasten sicherlich inakzeptabel - aber die Masse sind nunmal 0815 Heiopeis. :D

[DinosaurusRex]

Davon sind wir noch einige Jahrzehnte entfernt. Die Latenzen sind einfach tödlich. Cloud ist heute für eine einzige Sache sinnvoll... Savegames.

Jeder Samsung TV wird seit 2015 mit PlayStation Now ausgestattet (vermutlich weil SCE das Morpheus OLED von denen kauft und nicht von LG). Ars Technica schreibt über PS Now an Samsung TVs bspw:

The latency is really impressive. Even on action-y games like Street Fighter, you'd be hard pressed to notice that the game isn't native. Sony recommends a 5Mbps hardwired connection, but we ignored that and did Wi-Fi anyway, and it worked fine. We did run into a single "bad connection" session that had some screen tearing, but after exiting and relaunching the game, everything was fine.

Quelle (http://arstechnica.com/gaming/2015/07/hands-on-with-playstation-now-on-a-samsung-smart-tv/)

Diese Technik steht unmittelbar vor der Tür. Glaubst du Sony kauft sich zum Spaß und trotz jahrelanger Verluste sämtliche Streaming-Unternehmen zusammen? Herb Sutter hat über diese Entwicklung bereits 2005 einen Aufsatz geschrieben, der ist davon überzeugt, dass es ab 2020 total egal sein wird, wie deine Hardware aussieht, alle werden die gleiche Rechenleistung haben. Und du kannst deinen Arsch darauf verwetten, dass Microsoft genau aufgrund dieser Entwicklung überhaupt erst in den Konsolenmarkt eingestiegen ist.

[dargo]

Den meisten Heiopeis dürfte das, wie auch schlechterer Auflösung wenig ausmachen. Ob es 10 ms lag oder 100 ms ist, merken viele nicht. Insbesondere, wenn man mit Gamepad am TV spielt.

Um es mal mit deinen Worten zu sagen. ;)

Es gibt aktuell mindestens 38 Millionen Heiopeis (PS4 + XBox One). Und selbst dort ist man noch nicht durchgehend bei 1080p angekommen. Der nächste Schritt beim TV ist 4k. Das wird man sicherlich mit den nächsten Konsolen irgendwo in ~2020 anvisieren. Wie willst du sowas mit der Cloud bewerkstelligen? Das wird höchstes bei irgendwelchen latenz unkritischen Casual Games funktionieren, mehr aber auch nicht.

Jeder Samsung TV wird seit 2015 mit PlayStation Now ausgestattet (vermutlich weil SCE das Morpheus OLED von denen kauft und nicht von LG). Ars Technica schreibt über PS Now an Samsung TVs bspw:



Quelle (http://arstechnica.com/gaming/2015/07/hands-on-with-playstation-now-on-a-samsung-smart-tv/)

Diese Technik steht unmittelbar vor der Tür. Glaubst du Sony kauft sich zum Spaß und trotz jahrelanger Verluste sämtliche Streaming-Unternehmen zusammen? Herb Sutter hat über diese Entwicklung bereits 2005 einen Aufsatz geschrieben, der ist davon überzeugt, dass es ab 2020 total egal sein wird, wie deine Hardware aussieht, alle werden die gleiche Rechenleistung haben. Und du kannst deinen Arsch darauf verwetten, dass Microsoft genau aufgrund dieser Entwicklung überhaupt erst in den Konsolenmarkt eingestiegen ist.
Street Fighter ist auch super komplex. :freak: Und wo sind die Messwerte? Subjektive Eindrücke überzeugen mich nämlich nicht.

[N0Thing]

Es gibt aktuell mindestens 38 Millionen Heiopeis (PS4 + XBox One). Und selbst dort ist man noch nicht durchgehend bei 1080p angekommen. Der nächste Schritt beim TV ist 4k. Das wird man sicherlich mit den nächsten Konsolen irgendwo in ~2020 anvisieren. Wie willst du sowas mit der Cloud bewerkstelligen? Das wird höchstes bei irgendwelchen latenz unkritischen Casual Games funktionieren, mehr aber auch nicht.

Ich sehe ehrlich gesagt eher 4K Gaming via Streaming als 4K Gaming nativ auf einer Heimkonsole für 400€. Beim Streaming ist es nur eine Frage der Bandbreit, Kompression und der Serverfarm. Bei der Heimkonsole der nächsten Generation nicht vorstellbar, wenn es mehr als Tetris sein soll.

[DinosaurusRex]

Ich hab mich vor zehn Jahren, als Sutter seinen Aufsatz veröffentlicht hat, ohne DSL und dafür mit nem megaschlechten Ping durch Molten Core gelaggt. Ein 56k Modem hat ausgereicht. Damals waren die Spieler mit ISDN die Helden in World of Warcraft. Patch Day bedeutete zwei Tage nicht spielen. Glaubst du da hätte auch nur einer davon geträumt, dass es irgendwann mal so ist wie heute? Glaubst du sowas wie Google Fiber ist ein reines Prestige-Projekt? Oder Facebook Aquila? Die verschleudern das Geld nicht zum Spaß.

TV-Unternehmen schießen Satelliten in den Orbit. Lass dir das mal auf der Zunge zergehen. Was spricht dagegen, dass dir ein Medienunternehmen die Bandbreite zugänglich macht, die du für Cloud Gaming benötigst?

[stimulator]

http://lg.io/2015/07/05/revised-and-much-faster-run-your-own-highend-cloud-gaming-service-on-ec2.html

Hiermit kann man sich mal selber mit Steam In-Home Streaming etwas bauen, damit man ein Gefühl bekommt, wie stark einem die Latenz tatsächlich stört. Hatte ich damals im Juli auch gleich mal ausprobiert und prinzipiell schon OK. Fühlt sich mit Maus + Tastatur wie Pre-Render-Limit auf 6 oder 7 an :ugly:

Spiele mit Gamepad waren echt brauchbar, Assassin's Creed III blieb mir besonders gut in Erinnerung, weil es sich fast nativ anfühlte.

[dargo]

http://lg.io/2015/07/05/revised-and-much-faster-run-your-own-highend-cloud-gaming-service-on-ec2.html

Hiermit kann man sich mal selber mit Steam In-Home Streaming etwas bauen, damit man ein Gefühl bekommt, wie stark einem die Latenz tatsächlich stört. Hatte ich damals im Juli auch gleich mal ausprobiert und prinzipiell schon OK. Fühlt sich mit Maus + Tastatur wie Pre-Render-Limit auf 6 oder 7 an :ugly:

Geil... ich kotze schon bei 3 und min. 40fps. :usweet:

[DinosaurusRex]

Geil... ich kotze schon bei 3 und min. 40fps. :usweet:

Die werden dich mit exklusiven Spielen, einem kostenlosen Testmonat und niemals dagewesener Pornografik locken. Und wenn du nicht kotzen solltest, wirst du merken, dass du die 700€ für deine high-end Grafikkarte auch sinnvoller hättest investieren können, warts nur ab.

http://24.media.tumblr.com/tumblr_mblot5dMEZ1qh59n0o1_500.gif

---

Am interessantesten finde ich ja die Frage, über was sich die Gamer dann im Internet aufregen wollen? Das Thema Grafik dürfte dann ja sicher vom Tisch sein. Oder laufen "The way it's meant to be streamed"-Spiele auf Rechenzentren, die Nvidia Hardware nutzen, dann mit zusätzlichen Effekten?

[Hübie]

Na ja. Maximal gibt es eine Dual-GPU mit zwei GM204 und 16GB VRAM. Die teil man sich aber nach wie vor mit anderen. Also wie gut kann da die Grafik schon werden? ;)

[dargo]

Ich sehe ehrlich gesagt eher 4K Gaming via Streaming als 4K Gaming nativ auf einer Heimkonsole für 400€.
Warum? In 2020 sind wir schon deutlich weiter als man es 2013 war. Und ich sagte 4k anvisieren. Das heißt nicht, dass jedes Spiel dann mit 4k auch läuft. In 2020 sehe ich jedenfalls keine Probleme für eine Konsole @4k für 400-500€ und nur 30fps. Man hätte dann sogar die Option auf 1080p und 60fps zu gehen. Der Unterschied in der Auflösung dürfte nicht sehr vielen bei dem üblichen Sitzabstand auffallen. Die Interpolation auf 1/4 sollte sehr gut sein.

Die werden dich mit exklusiven Spielen, einem kostenlosen Testmonat und niemals dagewesener Pornografik locken. Und wenn du nicht kotzen solltest, wirst du merken, dass du die 700€ für deine high-end Grafikkarte auch sinnvoller hättest investieren können, warts nur ab.

Da muss ich dich enttäuschen. Ich habe noch nie 700€ für eine Grafikkarte bezahlt. Die letzte hatte mich effektiv exakt 196€ (Neupreis 340€) gekostet. :ufinger: Im übrigen nützt mir die beste Pornografik gar nichts wenn sich die Steuerung wie Kaugummi anfühlt. Spielspaß ist dann nämlich gleich Null.

[Affinator]

Ich hab mich vor zehn Jahren, als Sutter seinen Aufsatz veröffentlicht hat, ohne DSL und dafür mit nem megaschlechten Ping durch Molten Core gelaggt. Ein 56k Modem hat ausgereicht. Damals waren die Spieler mit ISDN die Helden in World of Warcraft. Patch Day bedeutete zwei Tage nicht spielen.

Da muss der Pedant in mir zuschlagen. Ich war damals WoW-Betatester (das reine WoW; keine Addons) und hatte schon eine vernünftige DSL-Leitung. Und das auf dem Dorf... Da stimmt was mit deinem Zeitgefüge nicht ganz.

[N0Thing]

Warum? In 2020 sind wir schon deutlich weiter als man es 2013 war. Und ich sagte 4k anvisieren. Das heißt nicht, dass jedes Spiel dann mit 4k auch läuft. In 2020 sehe ich jedenfalls keine Probleme für eine Konsole @4k für 400-500€ und nur 30fps. Man hätte dann sogar die Option auf 1080p und 60fps zu gehen. Der Unterschied in der Auflösung dürfte nicht sehr vielen bei dem üblichen Sitzabstand auffallen. Die Interpolation auf 1/4 sollte sehr gut sein.


Weil die Entwickler wie auch schon bei dieser, der letzten und den Konsolen davor ebenso bei der nächsten Generation den besten Kompromiss anstreben werden. Und da steht 4K wie heute auch FullHD nicht ganz oben auf der Liste. Vor PS4 und XbOne würde auch von FullHD als Standard mit 60fps spekuliert und wie weit sind wir da gekommen?

[dargo]

Weil die Entwickler wie auch schon bei dieser, der letzten und den Konsolen davor ebenso bei der nächsten Generation den besten Kompromiss anstreben werden. Und da steht 4K wie heute auch FullHD nicht ganz oben auf der Liste. Vor PS4 und XbOne würde auch von FullHD als Standard mit 60fps spekuliert und wie weit sind wir da gekommen?
Ich weiß nicht so recht was du unter "anvisieren" nicht verstehst? Spiele haben unheimlich große Skalierungsmöglichkeiten. Das fängt bei der Framerate an, geht über die tatsächliche GPU-/CPU-Last und endet bei reduzierten Details falls das Target nicht erreicht werden kann.

[N0Thing]

Ich verstehe anvisieren sehr gut. Nur wird meiner Meinung nach noch immer FullHD anvisiert und selten erreicht und du sprichst davon, dass die nächste Generation schon 4K im Blick haben soll. Erinnert mich einfach an die Seifenblasen, die schon vor der aktuellen Generation durch die Foren wehten.

Wenn du das nicht verstehst, sollten wir diese Diskussion lieber einstellen, ist eh OT.

[robbitop]

Die Übertragung von 4K wird theoretisch 4x so viel Bandbreite kosten wie FullHD. Die hälfte davon erzielt man in etwa mit neueren Kompressionsalgorithmen. Die andere Hälfte durch steigende Bandbreiten der Heiminternetanschlüsse. Bis 2020 sollte das durchschnittliche Bandbreitenniveau um diesen Faktor sicherlich steigen.

Es ist sicherlich mittelfristig machbar. Die Latenz wird nie toll sein. Aber für die Gamepad-Leute mit durchschnittlicher Wahrnehmung wird es vermutlich ausreichen.

Ich selbst wäre nie zufrieden - aber Enthusiasten sind eine Marktnische. Leider.

[DinosaurusRex]

Da muss der Pedant in mir zuschlagen. Ich war damals WoW-Betatester (das reine WoW; keine Addons) und hatte schon eine vernünftige DSL-Leitung. Und das auf dem Dorf... Da stimmt was mit deinem Zeitgefüge nicht ganz.

Ich hatte damals noch kein DSL. Das hab ich erst so mittig zwischen Vanilla Launch und BC bekommen. Molten Core hab ich mit 56k geraidet und damit war ich nicht der einzige bei uns in der Gruppe.

[Guest83]

Es ist sicherlich mittelfristig machbar. Die Latenz wird nie toll sein. Aber für die Gamepad-Leute mit durchschnittlicher Wahrnehmung wird es vermutlich ausreichen.

Ich selbst wäre nie zufrieden - aber Enthusiasten sind eine Marktnische. Leider.
Streaming ist aber inkompatibel mit VR, wo jede Zehntel Millisekunde zählt und das wird in Zukunft speziell im Gaming-Bereich eine große Rolle spielen.


Ich glaube Valve bereitet sich eher auf eine Cloud Gaming-Zukunft vor
Ganz im Gegenteil, Valve hat sich immer wieder negativ zu Streaming über das Internet geäußert. Deren Vision geht in eine ganz andere Richtung, nämlich dem Verschmelzen zwischen Consumer und Content-Creator. Das ist worauf sich Valve vorbereitet und das ist im Grunde das genaue Gegenteil von Streaming, wo ja nicht einmal mehr Modding möglich wäre.

[DinosaurusRex]

Streaming ist aber inkompatibel mit VR, wo jede Zehntel Millisekunde zählt und das wird in Zukunft speziell im Gaming-Bereich eine große Rolle spielen.

Dann machst du den Client halt fetter und packst ihn direkt in das HMD.

und das ist im Grunde das genaue Gegenteil von Streaming, wo ja nicht einmal mehr Modding möglich wäre.

Ich sehe da keinen Zusammenhang.

[Hübie]

Streaming ist aber inkompatibel mit VR, wo jede Zehntel Millisekunde zählt und das wird in Zukunft speziell im Gaming-Bereich keine große Rolle spielen.

fixed that for you :cool:

Das ist allenfalls ein Trend oder ein Übergang. Die wenigsten wollen so ein Teil auf der Birne. Eher augmented reality.

[DinosaurusRex]

Nochmal zu VR Streaming:

Es würde doch sicher ausreichen, wenn die lokale Hardware schnell genug ist, um die Bewegung des Spielers zügig zu verarbeiten und um wichtige Gameplay-Elemente zu berechnen.

Ansonsten könnte man die Szene in der Cloud doch immer mit einer vollen Rundumsicht "puffern" und dann nur noch den Teil auf dem Bildschirm ausgeben, der je nach Kopfposition benötigt wird.

Oder nicht?

[Skysnake]

Und dann dürfen die Leute nicht vorwärts laufen usw. oder wie?

[kruemelmonster]

Taugt der (openGL Pfad) denn was mit den Karten/Treibern der aktuellen Hersteller?
nVidia gehe ich stark davon aus, aber AMD und Intel? Gab ja seit Jahren keinen AAA Titel mehr der OpenGL voraussetzte, daher war es auch ziemlich wayne was die Treiber in dieser Disziplin leisten konnten...

Nur aus der Hüfte geschossen:

Wolfenstein + Addon
Rage
Planetary Annihilation
Doom 3 BFG
Chronicles of Riddick

Dazu kommt noch alles was auch unter Linux läuft, wie Bioshock Infinite, Dirt Showdown, Company of Heroes 2 und alles von Valve....und nach den aktuellen Benchmarks von www.phoronix.com hat AMD noch einen weiten Weg vor sich um zum NV OpenGL Treiber aufzuschliessen.

[Guest83]

Ich sehe da keinen Zusammenhang.
Ist halt schwer Content für ein Spiel zu modifizieren wenn man nur einen Videostream präsentiert bekommt.


fixed that for you :cool:

Das ist allenfalls ein Trend oder ein Übergang. Die wenigsten wollen so ein Teil auf der Birne. Eher augmented reality.
Lass mich raten, du hast noch nicht selbst eine Rift CV1 oder HTC Vive ausprobiert, korrekt?


Oder nicht?
Nein.

[aufkrawall]

Beim Wolfenstein Add On kommt die Fury X im Vergleich zu einer 980 Ti in der aktuellen PCGH extrem mies weg.

[just4FunTA]

Ist halt schwer Content für ein Spiel zu modifizieren wenn man nur einen Videostream präsentiert bekommt.

Ne das ist kein Problem, die moder würden dann ganz normal das sdk ziehen und damit eine map, skin oder waffen bzw playermodel erstellen und dieses dann bei Valve hochladen. Am ganzen Voting wie in csgo was dann tatsächlich ins Spiel kommt müsste sich nicht mal was ändern im Vergleich zu heute.

Also das moden ist wenn es der Publisher/Entwickler will auch bei Streaming kein Problem.

[][immy]

Nochmal zu VR Streaming:

Es würde doch sicher ausreichen, wenn die lokale Hardware schnell genug ist, um die Bewegung des Spielers zügig zu verarbeiten und um wichtige Gameplay-Elemente zu berechnen.

Ansonsten könnte man die Szene in der Cloud doch immer mit einer vollen Rundumsicht "puffern" und dann nur noch den Teil auf dem Bildschirm ausgeben, der je nach Kopfposition benötigt wird.

Oder nicht?
Man forscht ja derzeit an Techniken wo teile in der Cloud und teile zu Hause berechnet werden. Die Latenz versucht man unter anderem dadurch in den Griff zu bekommen, in dem man mehrere Möglichkeiten durchgeht wie der nächste Frame aussehen könnte. in ~90% der Fälle lässt sich das gut vorhersehen, ohne das die nächsten Steuerungsbefehle angekommen sind. Das dumme sind immer nur die letzten 10%. Man müsste aber schon in Bereiche von 30ms kommen, damit man das überhaupt sinnvoll verwenden kann. 60fps kann man wohl mehr oder minder vergessen, denn in 16ms noch die Übertragungslatenz mit rein zu bringen ...
naja, ich kann mir eher vorstellen das hybriden kommen. Da fährt MS aktuell gar nicht so verkehrt mit ihrer Cloud für die xbox. Physik-Berechnungen etc lassen sich herrlich einsparen und können extrem komplex werden. Und falls mal die Cloud nicht da ist könnte man noch immer auf "verbilligte" modelle zurückgreifen. Oder wie bei komplett-streaming angeboten einfach stoppen.

Was mir dabei eigentlich noch Bauchschmerzen bereitet. Das ganze ist herrlich ineffizient. Selbst wenn z.B. in Azure einmal spezialisierte Hardware stehen sollte ists doch einen ziemliche Ressourcenverschwendung, für das was am ende dabei rauskommt.

Das mit den Latenzen bekommt man vielleicht noch eher in den griff indem man mehr Rechenzentren baut die sich gut verteilen. Der Internet-Anschluss als solcher ist nur eine Frage der zeit, aber allen wird man es vermutlich nie recht machen können, das ist aber auch aktuell der Fall.

[Skysnake]

Die "Effizienz" bekommst einfach dadurch, dass du davon ausgehst, das an sich eigentlich eh nie mehr als 20-50% der Nutzer gleichzeitig spielen. Wenn du einen weltweiten Dienst hättest, könnteste sicherlich sogar von 10% ausgehen.

Es ist halt wie immer. Es gibt einige PowerUser, aber auf der anderen Seite noch viel mehr LowUser, die den Dienst fast gar nicht nutzen, und realistisch gesehen nutzen selbst PowerUser den Dienst maximal zu 50% der Zeit. Das Dumme dabei ist eben nur die Verteilung.... Hat man immer schön bei WOW gesehen. Nach jedem großen Patch usw. waren sehr viel mehr Nutzer als normal da, und es ging nichts mehr....

Aber das sind Probleme der Finanzabteilung.

Für uns Nutzer gibt es da ganz andere Probleme. Mit diesem drecks Cloud scheis haste nämlich das Gleiche Problem wie mit nicht dedicated Servern. Wenn der Hersteller meint, das nach 1-2 Jahren zu wenig Nutzer da sind, und es sich nicht mehr rechnet, bzw man eben die neue Version drausen hat, und du die doch bitte nutzen sollst, dann dreht er dir einfach den Saft ab, und du hast nur noch einen haufen Datenmüll auf der Platte....

Sehr schön auch aktuell der SecureDisk zu sehen. Da sind die ganzen Spiele mehr oder weniger jetzt auch Datenmüll....

[woodsdog]

Wer sich einmal etwas näher mit dem Steam in Home kram versucht hat wird schnell ernüchtert sein, gerade was potenzielles Internet-Streaming angeht.

Ich persöhnlich merke schon einen deutlichen Unterschied ob PC und Laptop sich im GBit LAN unterhalten oder ob das Laptop im WLAN ist....

via LAN geht vieles echt gut zu spielen, per WLAN schon weniger... Hier wurde AC genannt und das kann ich bestätigen. Geht prima, auch noch im WLAN. Racing Games hingegen finde ich schon mit LAN unspielbar. FPS ist komplett zu vergessen.

Wie aber Spiele abseits von Runden-basiert oder Aufbau-Sim vernümftig über das Internet spielbar sein sollen ist mir ein Rätsel... zumal der Großteil der Bevölkerung eben nicht über 50Mbit VDSL verfügt.

Von diesen Luftschlössern "zich fach vorausberechnen um Latenzen zu verstecken" ganz abgesehen... wer soll das bitte bezahlen wenn dann für einen user plötzlich 4 Grakas schuften müssten...? Das Problem der Bandbreite für den Käse mal ganz außen vor gelassen...

[Guest83]

[immy;10773572']Man forscht ja derzeit an Techniken wo teile in der Cloud und teile zu Hause berechnet werden. Die Latenz versucht man unter anderem dadurch in den Griff zu bekommen, in dem man mehrere Möglichkeiten durchgeht wie der nächste Frame aussehen könnte. in ~90% der Fälle lässt sich das gut vorhersehen, ohne das die nächsten Steuerungsbefehle angekommen sind. Das dumme sind immer nur die letzten 10%. Man müsste aber schon in Bereiche von 30ms kommen, damit man das überhaupt sinnvoll verwenden kann.
30 ms sind für VR völlig unbrauchbar. Richtiges VR funktioniert erst unter 20 ms und das ist die erste Generation, bei der wir uns in einigen Jahren fragen werden wie wir das ausgehalten haben. Das mittel- und langfristige Ziel sind 0 bis 7 ms Motion-to-Photon-Latenz. Nochmal: Cloud-Computing kann in VR nicht verwendet werden oder anders gesagt: VR ist eine Jobgarantie für jeden GPU-Engineer für die nächsten Jahrzehnte.

[DinosaurusRex]

[immy;10773572']
Was mir dabei eigentlich noch Bauchschmerzen bereitet. Das ganze ist herrlich ineffizient. Selbst wenn z.B. in Azure einmal spezialisierte Hardware stehen sollte ists doch einen ziemliche Ressourcenverschwendung, für das was am ende dabei rauskommt.

Vermutlich ist eher das Gegenteil der Fall. Eine Zentralisierung von Ressourcen ist in der Regel immer effizienter als eine Dezentralisierung. Das ist ja beispielsweise überhaupt der Grund, warum Atomkraftwerke bei Energiekonzernen so beliebt sind: Zentralisierter und ressourceneffizienter geht es heute gar nicht. Von dem Atommüll und der potenziellen Gefahr eines GAUs mal abgesehen, das ist ein anderes Thema, das an dieser Stelle keine Bedeutung hat. Für die Energieeffizienz würde sich Streaming mit Blick auf den gesamtgesellschaftlichen Ressourcenverbrauch sicher positiv auswirken, allerdings hat eine Zentralisierung von Ressourcen auch immer eine erhöhte Abhängigkeit des Individuums zur Folge und die Infrastruktur muss entsprechend ausgebaut werden.

Grundsätzlich finde ich den Vergleich zur Stromversorgung eigentlich sehr passend, denn er zeigt die möglichen positiven und negativen Auswirkungen, die bei so einer Umstellung eintreten könnten. Negativ wäre vor allen Dingen der Einfluss von Konzernen auf die Politik, Wettbewerbsverzerrungen durch Kartelle und die damit verbundenen, finanziellen Nachteile für das Individuum. Vorteil wäre hingegen, dass jeder Mensch ohne eine große Investition einen Zugriff auf eine enorme Menge an Ressourcen hätte. Alleine dadurch, dass AAA Gaming durch Streaming viel mehr Menschen zugänglich gemacht werden kann als es durch Spielkonsolen der Fall ist (von noch teurerer PC Gaming Hardware mal ganz zu schweigen), vergrößert sich der potenzielle Markt für die involvierten Unternehmen enorm. Das mal direkt zu dieser Aussage:


Von diesen Luftschlössern "zich fach vorausberechnen um Latenzen zu verstecken" ganz abgesehen... wer soll das bitte bezahlen wenn dann für einen user plötzlich 4 Grakas schuften müssten...? Das Problem der Bandbreite für den Käse mal ganz außen vor gelassen...

Wichtig ist halt nur, dass der Wettbewerb zwischen den Anbietern nicht in falsche Bahnen läuft. Diese Medaille hat zweifelsohne zwei Seiten.

---

Über die technischen Aspekte mach ich mir wenig Sorgen. Die Unternehmen stellen sich nicht grundlos um. Grundsätzlich gibt es bezüglich Nachrichten- und Kommunikationstechniken innerhalb der letzten 100 Jahre ein ganz klares Muster abzulesen: Erst wenn das Militär den nächsten technologischen Schritt machen kann, wird eine Nachrichtentechnik der Zivilbevölkerung zugänglich gemacht. Mich würde es also nicht wundern, wenn das alles bald ganz, ganz schnell geht und neue Techniken regelrecht vom Himmel regnen.

Es gibt nur physikalische Grenzen. Alles andere ist machbar.

Wenn ein US-Soldat, der in einer Militärbasis in Nordamerika sitzt, am anderen Ende der Welt einem Araber mit einem fliegenden Roboter bei ein paar hundert Stundenkilometern aus zigtausend Metern in den Kopf schießen kann, dann würde ich mir um die Latenz von zukünftigen Videospielen keine Sorgen machen...

[][immy]

30 ms sind für VR völlig unbrauchbar. Richtiges VR funktioniert erst unter 20 ms und das ist die erste Generation, bei der wir uns in einigen Jahren fragen werden wie wir das ausgehalten haben. Das mittel- und langfristige Ziel sind 0 bis 7 ms Motion-to-Photon-Latenz. Nochmal: Cloud-Computing kann in VR nicht verwendet werden oder anders gesagt: VR ist eine Jobgarantie für jeden GPU-Engineer für die nächsten Jahrzehnte.
Ups, das VR hatte ich total überlesen. Mein Post bezog sich auf normales Spiele-Streaming :)

Vermutlich ist eher das Gegenteil der Fall. Eine Zentralisierung von Ressourcen ist in der Regel immer effizienter als eine Dezentralisierung. Das ist ja beispielsweise überhaupt der Grund, warum Atomkraftwerke bei Energiekonzernen so beliebt sind: Zentralisierter und ressourceneffizienter geht es heute gar nicht. Von dem Atommüll und der potenziellen Gefahr eines GAUs mal abgesehen, das ist ein anderes Thema, das an dieser Stelle keine Bedeutung hat. Für die Energieeffizienz würde sich Streaming mit Blick auf den gesamtgesellschaftlichen Ressourcenverbrauch sicher positiv auswirken, allerdings hat eine Zentralisierung von Ressourcen auch immer eine erhöhte Abhängigkeit des Individuums zur Folge und die Infrastruktur muss entsprechend ausgebaut werden.
Das eine hat mit dem anderen nix zu tun. Ja, Zentralisierte Rechner sind grundsätzlich zwar effizienter, aber wenn du davon ausgehst, das dafür alles mögliche vorberechnet, Möglichkeiten berechnet etc werden muss, damit es nur halbwegs funktioniert, dann frisst das ganze die Effiziens halt wieder auf. Es muss halt etwas zum Zeitpunkt x (welcher nur wenig ms entfernt ist) das korrekte Bild zurück geschickt werden, da die Latenz ansonsten alles wieder auffrisst. Die Leistung steht zwar insgesamt in der Cloud zur Verfügung, sie muss aber auch genutzt werden können. Grafik lässt sich zwar herrlich parallelisieren aber auch nur bis zu einem gewissen punkt, also stehen dir trotzdem immer nur "begrenzte" Ressourcen zur Verfügung. Trotzdem muss das Bild innerhalb kürzerer zeit berechnet sein, als bei einer Konsole die zu hause steht, da es noch über die Leitung muss. Selbst wenn wir davon ausgehen das die internetleitung in Zukunft bei ~1ms angekommen ist muss dieses noch dekodiert etc werden. Auch das kostet wertvolle ms, die von der Berechnungszeit abgezogen werden müssen.
Wenn man also die Zeit merklich reduzieren wollen würde, müssten alle möglichen Szenarien vorberechnet werden damit das Bild quasi instant über die Leitung geschickt werden kann. Das mag in 90% der Fälle halt relativ einfach vorhersehbar sein und somit könnte die Berechnung eines Bildes schon unmittelbar vor der anfrage fertig berechnet worden sein, aber die letzten 10% würde immer zu einer Verzögerung führen, da das vorberechnete Bild plötzlich doch nicht mehr dem entspricht was angefordert wurde (Richtungswechsel beim laufen, schuss den der Benutzer abgegeben hat, ...). Würde man also auch diese Situationen abfangen wollen, müssten man relativ viele Szenarien vorberechnen was absolute ressourcen-Verschwendung wäre.
Von dem verstärkten Traffic der dadurch entsteht mal ganz zu schweigen.

[Novum]

30 ms sind für VR völlig unbrauchbar. Richtiges VR funktioniert erst unter 20 ms und das ist die erste Generation, bei der wir uns in einigen Jahren fragen werden wie wir das ausgehalten haben. Das mittel- und langfristige Ziel sind 0 bis 7 ms Motion-to-Photon-Latenz. Nochmal: Cloud-Computing kann in VR nicht verwendet werden oder anders gesagt: VR ist eine Jobgarantie für jeden GPU-Engineer für die nächsten Jahrzehnte.
Falls VR irgendeine nennenswerte Bedeutung erlangt.

[DinosaurusRex]

Eher augmented reality.

Ich finde Augmented Reality auch interessanter als Virtual Reality, es ist eine charmante Brückentechnologie, bis Holografie irgendwann mal bezahlbar wird.

Nintendo hat da ja jetzt was ganz cooles für Smartphones vorgestellt:

tUlX77BKLyY

VR kann ich bisher noch nicht wirklich viel abgewinnen. Stereoskopie muss endlich verschwinden. 200 Jahre Kopfschmerzen sind genug. Zumal ich HMDs für Unterhaltungszwecke grundsätzlich nicht als brauchbar ansehe. Du kannst nix trinken dabei, keine rauchen, nix futtern, du schottest dich komplett ab, kriegst nicht mit wenn es an der Tür klingelt oder das Telefon. Das ist für Menschen, die ein Sozialleben haben, nicht umsetzbar. Mal angenommen meine Freundin möchte mich was fragen und ich bin nicht ansprechbar, weil ich so ein Teil auf dem Kopf habe, die macht das zwei, dreimal mit und dann schmeißt die das in den Müll. Was ist wenn du Kleinkinder hast? "Passt du kurz auf die Kids auf? Ich möchte VR spielen." Totaler Quatsch, wenn man mal genau drüber nachdenkt. Ich finde die Nachteile überwiegen einfach.

Wo ich mir VR sehr gut vorstellen kann sind Freizeitparks. Eine echte Achterbahn mit VR-Headset und zu 100% abgestimmten Bildmaterial wäre schon sehr geil. Oder sowas wie der Star Wars Simulator aus'm Disneyland. Das dauert nur zwei Minuten und es würde sich auch lohnen, ein 8k Panel pro Person zu befeuern. Da kannst du dann richtig viel Rechenleistung reinstecken.

[Hübie]

30 ms sind für VR völlig unbrauchbar. Richtiges VR funktioniert erst unter 20 ms und das ist die erste Generation, bei der wir uns in einigen Jahren fragen werden wie wir das ausgehalten haben. Das mittel- und langfristige Ziel sind 0 bis 7 ms Motion-to-Photon-Latenz. Nochmal: Cloud-Computing kann in VR nicht verwendet werden oder anders gesagt: VR ist eine Jobgarantie für jeden GPU-Engineer für die nächsten Jahrzehnte.

Theoretisch schon. Immerhin reden wir hier von Signalen mit ~1/2 Lichtgeschwindigkeit. Und ich hatte zuletzt auf der CeBIT so ein Ding auf. Genauso Müll wie in den 90ern als ich Doom damit spielte. Okay das stimmt nicht, aber es bringt einfach nicht langfristige Stimmung auf, weil das Ding irgendwann derbe nervt. Sogar meine 3DV Brille nervt irgendwann. Es wird sicher eine Nische bleiben. Allein der Entwicklungsaufwand ist ungleich höher. Wobei ich hier kein Maß kenne. Nur vom Hören-Sagen her.

[Kartenlehrling]

Da haben wir den Salat... auch noch eine deutsche Gameschmiede die es als erstes Aussprechen was ich vermute habe.

Aquanox Dev: Wir würden eine Implementierung von Async Compute nur in betracht ziehen, wenn kein NVIDIA Benutzer eingeschränkt wird
http://wccftech.com/aquanox-dev-async-compute-implementation-limit-nvidia-users/

Und das beste ist sie reden von Unreal Engine4.0 wo Gamesworks schon fest eingebaut ist.


http://www.golem.de/news/unterwasser-aquanox-sucht-community-1508-115845.html
Der Unterwasser-Klassiker Aquanox soll auf Basis der Unreal Engine 4 neu belebt werden

[dargo]

Abwarten. Wenn NV es über den Treiber schafft, dass die GPUs mit ASC nicht langsamer werden passt es doch.

Edit:
Achso... das ist ein Kickstarter-Projekt? Dann wundert es mich nicht.

[fondness]

Wunderbar, damit behindert Nvidia ein weiteres mal den Fortschritt. Ich bin ja wirklich gespannt wie das ausgeht, mein aktuell wahrscheinlichsten Szenario: Nvidia geht weiter auf Tauchstation und das Feature wird außer bei den AMD-Spielen ignoriert.

[Kartenlehrling]

Kickstarter-Projekt

Das ist kein Kickstarter-Projekt, das Spiel ist fertig,
es ist aber so lange in Entwicklung das sie damals noch mit DX9 :) angefangen haben,
nun wollen sie es auf D11 bzw. gleich auf DX12 umschreiben, aber dafür haben sie kein Geld gehabt.

[dargo]

Das ist kein Kickstarter-Projekt, das Spiel ist fertig,
es ist aber so lange in Entwicklung das sie damals noch mit DX9 :) angefangen haben,
nun wollen sie es auf D11 bzw. gleich auf DX12 umschreiben, aber dafür haben sie kein Geld gehabt.
Wie auch immer. Ein eher unbedeutendes Spiel im Vergleich zu den AAA-Produktionen wenn man nicht mal eine neue API finanziell stemmen kann.

[Kartenlehrling]

Und was hat das jetzt zu sagen?
In Deutschland sollte das Spiel eigentlich jeder kennen.

[dargo]

Und was hat das jetzt zu sagen?

Für mich persönlich heißt es folgendes... es ist ein Spiel mit eher sehr geringem Budget. Geld fehlt um die Engine auf den neuesten API-Stand zu bringen. Wenn das schon fehlt dann wundert es mich nicht, dass man eher kein Geld für ASC investieren möchte. Dann ist noch nicht mal klar ob eine Konsolenumsetzung folgt. Bei Golem heißt es das soll die Community entscheiden. Und wie gesagt ist noch gar nicht klar ob NV nicht von dem negativ Scaling mit ASC runterkommt. Alles noch ziemlich offen.

[Skysnake]

Abwarten. Wenn NV es über den Treiber schafft, dass die GPUs mit ASC nicht langsamer werden passt es doch.

Edit:
Achso... das ist ein Kickstarter-Projekt? Dann wundert es mich nicht.
Du meinst wohl eher, man macht es erst, wenn man mehr gewinnt als AMD...

Wenn man selbst 10% gewinnt, AMD aber 20%, dann hat man an sich eigentlich ~10% verloren. Also unterstützt man es nicht. Das ist ja das Perverse an allen von nVidia durchgeführten "Fortschritten". Man schiest sich selbst gerne ins eigene Bein, hauptsache die Konkurrenz wird noch härter getroffen...

[Godmode]

Unnötigen SPAM gelöscht.
Nur mal zur Erinnerung:

1. Wir sind im Technologieforum, hier soll es um die Technologie und die Hintergründe gehen.
2. Sachlich bleiben!

[Hübie]

Wunderbar, damit behindert Nvidia ein weiteres mal den Fortschritt. Ich bin ja wirklich gespannt wie das ausgeht, mein aktuell wahrscheinlichsten Szenario: Nvidia geht weiter auf Tauchstation und das Feature wird außer bei den AMD-Spielen ignoriert.

Wenn es nicht benötigt wird... Die Auslastung auf Maxwell ist offenbar schon sehr gut und man hat mit compute shader nicht unbedingt einen Vorteil.

[Blediator16]

Wenn es nicht benötigt wird... Die Auslastung auf Maxwell ist offenbar schon sehr gut und man hat mit compute shader nicht unbedingt einen Vorteil.


Also könnte man auch in Zukunft auf den Fortschritt verzichten :uup:

Das ist so wie man sagen würde, darmals haben wir keine Smartphones gebraucht also werden wir sie morgen auch nicht brauchen :biggrin:

Nur weil aktuell eine Notlösung gut genug ist, um eine gewisse Auslastung zu erreichen, heisst es noch lange nicht, dass paralleles abarbeiten von Aufgaben nicht wesentlich besser ist.

[Hübie]

Also könnte man auch in Zukunft auf den Fortschritt verzichten :uup:

Das ist so wie man sagen würde, darmals haben wir keine Smartphones gebraucht also werden wir sie morgen auch nicht brauchen :biggrin:

Nur weil aktuell eine Notlösung gut genug ist, um eine gewisse Auslastung zu erreichen, heisst es noch lange nicht, dass paralleles abarbeiten von Aufgaben nicht wesentlich besser ist.

Das stimmt. Natürlich ist parallele Auslastung in vielen Fällen besser. Nur bemesse ich dem async compute noch keine so große Bedeutung bei. Es ist einfach noch viel zu früh. Wie gesagt kann man nicht einfach alles über cs laufen lassen. Deine dummen Übertreibungen kannst du also lassen.

[Skysnake]

Man muss sich aber halt auch fragen, inwieweit sich die ganze Architektur von GPUs mit den in DX12 enthalten features wieder ändern kann.

Ich erinnere da nur mal an die Anfänge von CrossFire und den Überlegungen von ATI, wie man GPUs ASICs aufteilen und asymmetrisch machen kann. Da sind einige sehr sehr sexy Ansätze/Ideen dabei, die meiner Meinung nach gut mit den neuen APIs harmonieren.

[Gipsel]

Das ist jetzt die letzte Warnung. Noch einen Modtext gibt es nicht.

[Hübie]

Man muss sich aber halt auch fragen, inwieweit sich die ganze Architektur von GPUs mit den in DX12 enthalten features wieder ändern kann.

Ich erinnere da nur mal an die Anfänge von CrossFire und den Überlegungen von ATI, wie man GPUs ASICs aufteilen und asymmetrisch machen kann. Da sind einige sehr sehr sexy Ansätze/Ideen dabei, die meiner Meinung nach gut mit den neuen APIs harmonieren.

ATi hatte da viel Pulver verschossen, aber es kam nie viel an. Das Problem ist und war immer wieder die Bandbreite von und zum Zeitgerät. Dazu kommen ungleichmäßige Laufzeiten was eben die Frametimes wieder beeinflußt bzw. mit entsprechend hohem Mehraufwand die Arbeit wiederum nicht wert ist.

Tiling war da ein Ansatz der, wenn man es von vorn herein implementiert, sicher am sinnvollsten war, aber eben schwer realisierbar. Aktuell ist ja Lastverteilung ein Gebiet, auf dem man sich bewegt. Bei all den verkümmerten iGPUs wohl gar nicht so verkehrt, wenns denn gleichmäßige frametimes gibt.

[Skysnake]

Ich sagte doch schon, man kann die Chips asymmetrisch machen ;)

Schau dir doch mal eine heutige GPU an. Das ist zu einem ziemlich großen Teil erstmal eine reine General Purpose Compute Maschine, und erst danach wirklich ein Grafikchip. Zudem schau dir doch mal an, wie das an sich heutzutage organisiert ist mit der physikalischen Aufteilung der einzelnen Teilcomponenten die man Compute und Grafik zuteilen kann.

Da kann man sich schon sehr interessante neue Modelle vorstellen. Vor allem jetzt, wo man quasi alles in der eigenen Hand hat und bis zum Package 0 Rücksicht mehr nehmen muss auf irgend etwas.

[Hübie]

Ja das wäre durchaus möglich. Eine GPU besteht ja aus vielen Modulen wo auch Zukauf getätigt wird. Die Verbindung muss aber dennoch über ein Interposer erfolgen. Das kostet wieder. Ob sich dass linear in mehr Performance niederschlägt bezweifel ich erst mal, da es einen gemeinsamen Arbiter / Command Processor bräuchte der alles erst mal steuert (füttert). Die jeweils andere Logik muss ja wissen was der counterpart macht.
Da fände ich eine APU mit HBM erstmal sinnvoller.

[Kartenlehrling]

Ich wette das in 5-8 Jahren ein einfacher ARM-CPU ausreicht um 2-4 R9nano zu "verwalten".
AMD muss es schaffen das man keine Profile für Crossfire brauch, sie wie eine GPU behandelt wird und >90% Skaliert.
November werden wir ja die Dual Chip Karte R9nanoX2 sehen, diese wird zeigen wohin es geht.
AMD wird es uns zwar mit VR zeigen aber ich hoffe das es auch für einen 4k Monitor anzuwenden ist, für geteile Frame Bereichung haben sie ja schon Andeutunge gemacht.

[Skysnake]

Naja, den Interposer haben wir ja schonmal. Das ist also kein Problem mehr. Ansonsten muss man natürlich schon schauen, inwieweit man da Kommunikation zwischen den Einzelnen Teilbereichen braucht. Da bin ich dann leider auch in der reinen Grafikpipeline viel viel viel zu wenig drin, um das sicher beurteilen zu können, wie feingranular das Zusammenarbeitet. Wobei man sich schon klar darüber sein muss, das wir hier eher von 2-8 einzelnen DIEs nur reden und nicht von mehr! Also mit STacks als 1 DIE gerechnet.

Wie gesagt, da kann man sich an sich ziemlich einfach sehr viele unterschiedliche interessante Modelle vorstellen, und man kann gift darauf nehmen, dass die eine oder andere auch bereits in Umsetzung ist. Dafür sprechen einfach einige Patente. Zu dem ganzen Thema will ich aber gar nichts weiter mehr sagen. Da soll jeder sich selbst seine Gedanken machen.

[Locuza]

http://www.theastronauts.com/2015/09/the-vanishing-of-ethan-carter-redux-out-now/
Does the game support DirectX 12?

No, not yet. The current version of UE4 has an experimental support for DX12, and it really is experimental and thus too risky for a public release for us. As soon as there’s the final release, we will add this feature to the game.


Ich hoffe viele der Ankündigungen bewahrheiten sich, so wie der eig. geplante DX12 Patch für Project Cars.

[Schnoesel]

http://www.pcgameshardware.de/Spiele-Entwicklung-Thema-35261/News/Frostbite-Engine-DirectX-12-erstes-Spiel-1171016/

Mal sehen wie viele Frostbite Titel DX 12 an Bord haben werden.

[Locuza]

Das Thema Frostbite finde ich etwas seltsam.
Man war der Mantle Pionier und jetzt ist es relativ still geworden, was die Zukunft mit low-overhead APIs angeht.

Anderes Thema, Async Compute :D
Digital Foundry: Ultimate Edition is coming to DX12 and Windows 10 - can you talk us through how the engine takes advantage of the new API?

Cam McRae: We are still hard at work optimising the game. DirectX 12 allows us much better control over the CPU load with heavily reduced driver overhead. Some of the overhead has been moved to the game where we can have control over it. Our main effort is in parallelising the rendering system to take advantage of multiple CPU cores. Command list creation and D3D resource creation are the big focus here. We're also pulling in optimisations from UE4 where possible, such as pipeline state object caching. On the GPU side, we've converted SSAO to make use of async compute and are exploring the same for other features, like MSAA.
http://www.eurogamer.net/articles/digitalfoundry-2015-the-making-of-gears-of-war-ultimate-edition

[dargo]

Das Thema Frostbite finde ich etwas seltsam.
Man war der Mantle Pionier und jetzt ist es relativ still geworden, was die Zukunft mit low-overhead APIs angeht.

Was willst du da noch hören? Die LL-APIs sind da, jetzt müssen nur noch die Anwendungen folgen.

[Locuza]

Ich möchte hören, dass NFS, Star Wars und ME: Catalyst mit DX12 erscheinen. :P

In dem Bezug sind konkrete Ankündigungen allgemein etwas nebelig und schwammig.
Natürlich auch verständlich, dass nicht jeder so frühzeitig eine Garantie oder ähnliches verlauten lassen will.

[Kartenlehrling]

In einer Twitter Meldung wurde nachdem verlaute wurde das Fostbite3 nun auf DX12 umgestellt ist gefragt welch Spiele es sind und
da wurde geantworte auf jedenfall alle Fostbite3 Spiele die 2016 Release haben.

Dieses Jahr kommen ...Need for Speed, Starwars,
das diese Spiele auf der XBone mit DX12 kommen ist wohl sicher nur Welche API`s die PC Versionen unterstützen wissen wir immer noch nicht.


Ich möchte hören, dass NFS, Star Wars und Mirror's Edge Catalyst mit DX12 erscheinen.

Mirror's Edge Catalyst kommt Febuar somit 100% sicher ....

Was mir Sorgen macht ist das anscheinen Nvidia MirrorEdge supporte.

[Locuza]

Also bei https://twitter.com/bionicbeagle/with_replies finde ich nichts, auch nicht bei Johan.
Woher hast du das mit 2016 alle Frostbite 3 Games mit DX12?

[Unicous]

Dafür habe ich etwas eher Unschönes gefunden:

https://twitter.com/repi/status/642641525755789312

HEλVY ‏@HeavyHDx

@repi Will we see Frostbite games on Linux as well when Vulkan is released?

Johan Andersson ‏@repi

@HeavyHDx very unlikely


Johan Andersson
‏@repi

@HeavyHDx less then 1% of the potential audience, even Mac (which we don't support) is more than 3x larger. http://store.steampowered.com/hwsurvey


Da wird sich Arcanoxer wohl heute in den Schlaf weinen.

[iuno]

Dafür habe ich etwas eher Unschönes gefunden:

https://twitter.com/repi/status/642641525755789312


Da wird sich Arcanoxer wohl heute in den Schlaf weinen.
Don't trigger the troll... :P
Aber davon abgesehen ist es wirklich 'traurig'. Gerade von DICE habe ich mir mehr erhofft. Aber was erwartet man noch, wenn selbst AMD schon DX12 als den Standard anpreist.
Und die "Begründung" ist ja wohl Blödsinn 1. Klasse. Immerhin wurde (noch) nicht ausgeschlossen, überhaupt mal auf Vulkan laufende Spiele anzubieten, denn dann müsste er auch rechtfertigen, warum die restlichen 79% der potential audience nur "minderwertiges" DX11 vorgesetzt bekommen :rolleyes: - davon mal ganz abgesehen, dass es DICE Titel nur noch über Origin und nicht auf Steam gibt.

[Unicous]

Du meinst von EA hast du dir mehr erwartet und sage ich dir: bei EA sollte man seine Erwartungen immer ganz nach unten schrauben, denn dann wird man u.U. sogar noch überrascht.:eek:

Vllt. folgt z.B. auf BF4 gar BF6 und nicht 5.:uroll:

[iuno]

Gut, eigentlich nicht wirklich ;)
Naja, wenn man es damit begründet dass 2142, die Bad Company Teile und jetzt noch BFH doch mitgezählt wären, wäre "BF5" sogar eigentlich "BF9"!!111 :freak:
Da die 9 aber bekanntlich kein Glück bringt wird man es direkt BFX(10) nennen, wie bei Windows ;D

Aber ernsthaft: Für einen logisch denkenden Menschen macht das doch keinen Sinn. Ich bin aber auch kein BWLer :rolleyes:

[KingBert]

Aber davon abgesehen ist es wirklich 'traurig'. Gerade von DICE habe ich mir mehr erhofft. Aber was erwartet man noch, wenn selbst AMD schon DX12 als den Standard anpreist.
Ohne einen zweistelligen Marktanteil wird sich da schlicht nichts bewegen. DX12 ist auf die nächsten Jahre immer noch die HauptAPI für den PC.

Eventuell ändern (Linux-)Steammachines etwas an der Vormachtstellung von DX.

[Kartenlehrling]

Ich habe das schon einmal gefragt, aber die Antworten waren nicht befriedigend.
Welches Tool nimmt den jetzt schon DX12 auf und kann auch HWinfo64 als OSD annehmen.
MSI-Afterburner scheint es im moment ja nicht zu können.

Habe das hier gerade im Steam gelesen, mhhh also auch noch nicht.

DX12-Filmaufnahme und Live-Streaming-Funktion wird in Kürze verfügbar sein.

D3DGear 4.97 Build 1955 is avaliable 12. SEPTEMBER - D3DGEAR
Change log:

Supports displaying FPS overlay for DX12 games. D3DGear is the only recording software that currently supports displaying DX12 FPS overlay.
DX12 movie recording and live streaming function will be available soon.
Improved DX10 and DX11 game recording and game live streaming performance.

[Hübie]

Gibt ja außer diesen Drawcall-Test noch nix mit D3D12 oder irre ich? Ich glaube der Framecounter von GFE funktioniert immer.

[DinosaurusRex]

Aber davon abgesehen ist es wirklich 'traurig'.

Richtig traurig wäre es erst, wenn Async Compute in ein und dem selben Multiplat auf den Konsolen unterstützt werden würde, auf dem PC aber gar nicht. Das wäre wirklich ein Armutszeugnis.

[aufkrawall]

Richtig traurig wäre es erst, wenn Async Compute in ein und dem selben Multiplat auf den Konsolen unterstützt werden würde, auf dem PC aber gar nicht. Das wäre wirklich ein Armutszeugnis.
Nur blöd, dass schon mehrere Entwickler es für den PC angekündigt haben.
Ist dein feuchter Traum wohl schon größtenteils geplatzt.

[Unicous]

Nur blöd, dass schon mehrere Entwickler es für den PC angekündigt haben.
Ist dein feuchter Traum wohl schon größtenteils geplatzt.

Und dann gibt es auch Entwicklerstimmen die sagen, dass sie z.B. Async Compute nicht verwenden würden, wenn ein IHV "benachteiligt" wird.;)

[DinosaurusRex]

Nur blöd, dass schon mehrere Entwickler es für den PC angekündigt haben.
Ist dein feuchter Traum wohl schon größtenteils geplatzt.

Ich hab das wortwörtlich gemeint.

[aufkrawall]

Und dann gibt es auch Entwicklerstimmen die sagen, dass sie z.B. Async Compute nicht verwenden würden, wenn ein IHV "benachteiligt" wird.;)
Da gibts bisher afaik nur eine Entwicklerstimme, und die ist nicht besonders wichtig.
Und die wird auch ganz schnell wieder verstummen, falls NVs CPU-Gebastel negative Skalierung verhindert.

[Hübie]

Man kann alles auf die Goldwaage legen, wenn man denn will... Das Thema async compute is ja nun in aller Munde, aber wird wohl wieder verstummen wenn es denn erste Ergebnisse, statt Anmutungen gibt.
Damit meine ich fertige, kaufbare Produkte.

[aufkrawall]

Wenn NV es verkackt, kann es auch genau so gut ein Evergreen werden.

[Unicous]

Wenn NV es verkackt, kann es auch genau so gut ein Evergreen werden.

Weder Nvidia noch AMD werden wohl zu VLIW zurückkehren.


SCNR



Es ist nur eine Stimme die explizit von Async Compute gesprochen hat. Es könnte aber u.U. Entwickler geben die sich vllt. gar nicht erst die Mühe machen Async Compute zu nutzen, wenn es bedeutet, dass sie für die IHVs (auch Intel hätte wohl mit AC Probleme, so interpretiere ich jedenfalls Lauritzens Kommentare) einen workaround einbauen müssen.

[aufkrawall]

Hat das Nostradamus vorhergesagt?
Der Renderpfad muss eh auf die IHVs angepasst werden, mit DX12 womöglich im Detail noch mehr als mit 11.
Ist komplett müßig, darüber zu spekulieren. Überlassen wir das mal lieber den Profis.

[DinosaurusRex]

Früher oder später werden ALLE Spiele mit DX12 laufen. Da gibt es doch gar nix zu diskutieren. Ist alles nur eine Frage der Zeit.

[aufkrawall]

In welchem Kontext steht deine Aussage zu den vorangegangenen Posts? Ist mir nicht klar.

[iuno]

Und dann gibt es auch Entwicklerstimmen die sagen, dass sie z.B. Async Compute nicht verwenden würden, wenn ein IHV "benachteiligt" wird.;)
Da gibts bisher afaik nur eine Entwicklerstimme, und die ist nicht besonders wichtig.
Wer war das?

Früher oder später werden ALLE Spiele mit DX12 laufen. Da gibt es doch gar nix zu diskutieren. Ist alles nur eine Frage der Zeit.
Unsinn. Valve wird z.B. sicherlich nicht auf DX12 gehen.
Davon abgesehen heißt das nicht, dass AC auch genutzt wird

[aufkrawall]

Wer war das?

Aquanox-Entwickler:
http://wccftech.com/aquanox-dev-async-compute-implementation-limit-nvidia-users/
Das Spiel ist wahrscheinlich höchstens zu 20% fertiggestellt und vor Kurzem gabs eine fragwürdige PR Kickstarter-Kampagne...

[DinosaurusRex]

Unsinn. Valve wird z.B. sicherlich nicht auf DX12 gehen.

Und wie viele Spiele produziert Valve jedes Jahr?

[Novum]

Ich bin mir nicht so sicher, ob DirectX 12 wirklich das Rennen gewinnt gegen Vulkan. Vulkan hat den großen Vorteil, dass es auf Windows 7/8 läuft. Die Installationsbasis ist viel größer.

[iuno]

Und wie viele Spiele produziert Valve jedes Jahr?
Dein Ernst?
Früher oder später werden ALLE Spiele mit DX12 laufen. Da gibt es doch gar nix zu diskutieren. Ist alles nur eine Frage der Zeit.
Originalzitat, die Kapitalisierung nicht von mir :rolleyes:
Valve war außerdem nur ein Beispiel. Es gibt übrigens auch noch indie devs abseits der großen Studios und Publisher
Ich bin mir nicht so sicher, ob DirectX 12 wirklich das Rennen gewinnt gegen Vulkan. Vulkan hat den großen Vorteil, dass es auf Windows 7/8 läuft. Die Installationsbasis ist viel größer.
Deswegen verstehe ich ja auch nicht, warum so ein Wind um DX12 gemacht wird oder warum man es als Entwickler (der bei klarem Verstand ist) überhaupt unterstützen soll – von der Übergangszeit mal abgesehen.
Wenn man aber sowas liest wie alle zukünftigen DICE Spiele kommen mit DX12 hat das mit Übergangszeit wohl wenig zu tun.

[aufkrawall]

Ich bin mir nicht so sicher, ob DirectX 12 wirklich das Rennen gewinnt gegen Vulkan. Vulkan hat den großen Vorteil, dass es auf Windows 7/8 läuft. Die Installationsbasis ist viel größer.
Kannst du schon etwas zur Effizienz beider APIs im Vergleich (aufgrund der Sepcs) spoilern?

[Lurtz]

Ich bin mir nicht so sicher, ob DirectX 12 wirklich das Rennen gewinnt gegen Vulkan. Vulkan hat den großen Vorteil, dass es auf Windows 7/8 läuft. Die Installationsbasis ist viel größer.
Das wird es mit ziemlicher Sicherheit. Genau wie Windows das Betriebssystem der Wahl für Spieler bleiben wird. Alles andere sind IMO nur Schönträumereien.

[-/\-CruNcher-/\-]

Ich bin mir nicht so sicher, ob DirectX 12 wirklich das Rennen gewinnt gegen Vulkan. Vulkan hat den großen Vorteil, dass es auf Windows 7/8 läuft. Die Installationsbasis ist viel größer.

Jep dieses mal sieht es anders aus als wie noch bei OpenGL man hat dazu gelernt vieles davon ist ohne zweifel AMD zu verdanken was schon etwas komisch ist bedenkt man das in der Xbox One eine AMD APU werkelt ;)

so gesehen hat nur die Xbox One einen genutzen DX 12 stack Sony könnte näher zu Vulkan rutschen was interoperabilität ihrer API angeht ;)

Aber Mobile spielt ja auch noch eine Rolle zumindestens sind die Vorausetzungen für diesmal 50/50 gegeben in wie weit Vulkan dann die Kosten senken kann werden wir ja erleben oder nicht und ob es wirklich so performant wie DX 12 auf dem NT Kernel wird diesmal :)

[Demirug]

Aber Mobile spielt ja auch noch eine Rolle zumindestens sind die Vorausetzungen für diesmal 50/50 gegeben in wie weit Vulkan dann die Kosten senken kann werden wir ja erleben oder nicht und ob es wirklich so performant wie DX 12 auf dem NT Kernel wird diesmal :)

Relativ. Apple setzt ja auf Metal das nun auch für OSX kommt. Bei Android gibt es verständlicherweise bisher nur eine Ankündigung das man es unterstützen wird. Allerdings noch ohne eine genaue Version anzugeben. Und wenn es dann kommt muss sich eigen wie schnell es eine kritische Masse erreicht. Man darf nicht vergessen das die Mehrheit der sich im Einsatz befindlichen Android Geräte immer nochnur OpenGL ES 2.0 unterstützen. Wer also auf Mobile mit einer Codebasis möglichst veile Gerte erreiche n will wird bei OpenGL ES 2.0 bleiben.

Bei Windows wird die wichtige Frage nicht die Performances sein. Sondern auf wie vielen Geräten es verfügbar ist. Also in wie weit es Vulkan Updates per Windows update geben wird.

Am Ende des Tages war es aber sowieso für die Entwickler von Multiplatformtitle kein großes Problem auf der jeweiligen Hardware die entsprechenden System API für eine Funktion zu nutzen.

[Hübie]

Ich bin mir nicht so sicher, ob DirectX 12 wirklich das Rennen gewinnt gegen Vulkan. Vulkan hat den großen Vorteil, dass es auf Windows 7/8 läuft. Die Installationsbasis ist viel größer.

Meinst du Masse oder Performance? Vulkan wird - und da lasse ich mich festnageln - bei weitem nicht in so vielen Engines implementiert wie D3D12. Weil stets allein der fallback auf D3D11 mit drin sein wird ist das Argument Win7/8 zumindest in den kommenden Jahren kein Problem. Danach regelt es sich von selbst, da der Support ausläuft.

Mobile Klammer ich hier stets aus, da völlig anders ausgerichtet. Die Spiele kann man nicht vergleichen.

[fondness]

Selbst wenn Vulkan vielleicht kurz aufleben wird, wird es mittelfristig wieder in der Versenkung verschwinden IMHO. Bestes Beispiel dafür ist eh die aktuelle Entwicklung. Man hat den gesamten Sourcecode von AMDs Mantle bekommen und trotzdem dauert es wohl noch ewig und drei Jahre bis mal wenigstens die finalen Specs stehen. Zu viele Köche verderben den Brei, MS ist da als einzelner Konzern wesentlich handlungsschneller, im Notfall werden die Specs einfach festgelegt und fertig. Und einen wirklichen Nachteil hat MS auch nicht, da eh 95% der Spieler auf Windows spielen und man Win10 faktisch gratis bekommt. Die Khronos-Group schafft es nicht sich zu einigen und wenn doch kommen meist nur faule Kompromisse raus.

[deekey777]

Bei DirectX tut Microsoft auch nur das, was ihm die IHVs am runden Tisch sagen.

[fondness]

Nur trifft MS dort auch mal eine Entscheidung, wenn es zu Unstimmigkeiten kommt (was da sicher auch oft genug der Fall sein wird). Die Khronos-Group hingegen will immer alle Mitglieder mit im Boot haben, das geht nicht gut.

[Arcanoxer]

Selbst wenn Vulkan vielleicht kurz aufleben wird, wird es mittelfristig wieder in der Versenkung verschwinden IMHO. Bestes Beispiel dafür ist eh die aktuelle Entwicklung. Man hat den gesamten Sourcecode von AMDs Mantle bekommen und trotzdem dauert es wohl noch ewig und drei Jahre bis mal wenigstens die finalen Specs stehen. Zu viele Köche verderben den Brei, MS ist da als einzelner Konzern wesentlich handlungsschneller, im Notfall werden die Specs einfach festgelegt und fertig.Was sind denn bitte "die finalen Specs"für dich?
Dir scheint gar nicht klar zu sein wie die Vulkan Entwicklung abläuft.

Ähnlich wie bei DirectX soll Vulkan in Feature-Levels untergliedert werden, sodass mit unterschiedlicher Hardware unterschiedliche Effekte erzielt werden können. Grundsätzlich kompatibel sind alle GPUs, die OpenGL ES 3.1 beziehungsweise OpenGL 4.x beherrschen – damit wird eine breite Riege an Desktop- und Mobile-Grafikkarten beziehungsweise -einheiten abgedeckt. Die Feature-Levels legt grundsätzlich der Plattforminhaber fest: Bei Android wird es Google sein, bei Steam OS wahrscheinlich Valve. Erst wenn ein Plattforminhaber das nicht erledigt, springt die Khronos Group ein, so etwa bei Microsofts Betriebssystemen möglich.
http://www.pcgameshardware.de/OpenGL-Software-141680/News/Vulkan-Finalisierung-Fertigstellung-1167712/

[Lurtz]

Warum sollte es bei Vulkan anders laufen als bei OpenGL? Das Geld und die Macht ist bei MS und die meisten großen Publisher folgen dem Geld.
Interessanter fände ich es schon ob Vulkan im Indiebereich durchstarten wird, aber gerade da wären fertige Konzepte wichtig, kein ewiges hin und her. Das ist der Tod für kleine Studios.

[BlacKi]

Nur trifft MS dort auch mal eine Entscheidung, wenn es zu Unstimmigkeiten kommt

irgendwie hat jeder sein eigenes DX12.

[AintCoolName]

Bei Windows wird die wichtige Frage nicht die Performances sein. Sondern auf wie vielen Geräten es verfügbar ist. Also in wie weit es Vulkan Updates per Windows update geben wird.

Ist das wirklich so ein Problem, müssen solche Sachen durch Windows Updates installiert werden damit sie sich durchsetzen. Können Platformen wie Steam oder das Spiel selbst nicht die nötigen Komponenten installieren? Geht es also nicht ohne die viel gehassten Windows Zwangsupdates? Warum ist das so?

[Ganon]

Warum sollte es bei Vulkan anders laufen als bei OpenGL?

Nicht vergessen, dass Vulkan keine reine Desktop-API ist. Und auf den marktführenden Telefonen und Tablets läuft OpenGL ES. Und auf diesen wird über kurz oder lang auch Vulkan verfügbar sein.

Auch steckt die Khronos Group jetzt mehr Arbeit in Tools rein. Damals gab es wirklich nur die API-Spezifikation... später dann mal einen Shader-Validator, aber jetzt sollen sogar wirklich Tools wie Compiler und Debugger kommen.

Mit dem angestaubten OpenGL würde ich das nicht mehr vergleichen. Und Direct X 12 ist für Android und iOS keine Option. Klar, Apple macht gerade noch einen Alleingang mit Metal. Ist die Frage ob sie nach Release noch daran festhalten und wie lange. Wäre nicht die erste API, die Apple wieder kickt.

Aber momentan wäre ich schon froh, wenn OpenCL nicht so ein Desaster wäre xD

[Demirug]

Ist das wirklich so ein Problem, müssen solche Sachen durch Windows Updates installiert werden damit sie sich durchsetzen. Können Platformen wie Steam oder das Spiel selbst nicht die nötigen Komponenten installieren? Geht es also nicht ohne die viel gehassten Windows Zwangsupdates? Warum ist das so?

Theoretisch kann es jede Software mit installieren solange es der User nicht aktiv selbst irgendwo herunter laden muss. Gerade Treiber sind aber da ein durchaus heißes Eisen und da dürften sich die wenigsten die Finger daran verbrennen wollen indem sie eine Treiber Installation zu ihrer eigenen dazu packen.

[aufkrawall]

Wieso sollte das ein Problem sein? Es werden bereits OpenGL, OpenCL und Cuda per WU installiert.

[fondness]

Was sind denn bitte "die finalen Specs"für dich?


Dir scheint nicht klar zu sein, was die Wortfolge "finalen Specs" bedeutet. Bis Jahresende sollen diese fixiert werden. DX12 ist derweilen schon verfügbar und dabei hatte Vulkan sogar einen Startvorteil.

[Demirug]

Wieso sollte das ein Problem sein? Es werden bereits OpenGL, OpenCL und Cuda per WU installiert.

Wenn es ein Treiberupdate gibt sollte das auch kein Problem sein. Leider kommt bei Nodebook halt häufig überhaupt kein Treiberupdate mehr.

Wie gesagt man muss abwarten wie viele System am Ende Vulkan wann fähig sein werden. Das Problem wird man auch bei Android haben. Hinzu kommt noch das im Moment halt auch keiner Sicher weiß wann man ein Spiel mit Vulkan überhaupt ausliefern kann. Es gibt nicht umsonst den Spruch: " Don't build Betas on Betas or you will end with a Final on Beta"

DX12 ist unter Windows im Moment einfach das sicherer Pferd.

[aufkrawall]

Ich könnte mir vorstellen, dass erstmal nur Vulkan-Spiele von Studios kommen, die schon Erfahrung mit Mantle haben.
Da ist der gute Draht zu AMD dann sicher nützlich.

Wobei Intel ja auch ziemlich drauf abfährt. Im Einzelfall könnte mir auch eine Zusammenarbeit eines Studios mit denen vorstellen, wie etwa bei Grid 2.

[Ganon]

Es ist auch die Frage wie es am Ende mit den Treibern generell aussehen wird. Da hat man ja auch bei OpenGL recht viel Stress. Intel hängt hinterher, und AMD und NVidia haben immer wieder ihre eigenen Bugs. Bei Direct3D sind da alle etwas näher beieinander.

Bei OpenCL ist es noch schlimmer. NVidia scheißt drauf und kümmert sich lieber um CUDA und bremst damit alle. AMDs Treiber sind zwar aktuell aber buggy/wählerisch und Intel liefert aktuell nur CPU Unterstützung und _sehr_ buggy GPU Unterstützung. In Kurz: Unbenutzbar.

Bei Vulkan könnte sich durch SPIR-V und offiziellem Compiler einiges ändern, aber das muss sich halt erst zeigen.

Aber wenn ein Spiel eh nur für Windows rauskommen soll, dann wird wohl kaum einer Vulkan verwenden. Bei AAA Multiplattform-Titeln hat man wahrscheinlich eh Pfade für alle APIs und bei höherwertigen Indie-Titeln kommt vllt. Vulkan zum Einsatz.

[-/\-CruNcher-/\-]

Bei DirectX tut Microsoft auch nur das, was ihm die IHVs am runden Tisch sagen.

Naja in der Windows 8 Mobile Entwicklung hat Microsoft aber ganz schön druck gemacht was sie von Zukünftiger Hardware erwarten vor allem der GPU ;)

Microsoft braucht diese Features für ein effizientes OS also gehen sie damit auch an den IHV und machen druck das zu implementieren ;)

Software leads Hardware and Hardware leads Software ;)

Vor allem ATI/AMD versuchte immer diese Anforderungen zu erfüllen Nvidia sah das ganze etwas anders ihre Strategie war immer so ausgerichtet die Features zum Richtigen Zeitpunkt zu liefern und resourcen für sie wichtigere parts einzusetzen ;)

Und Nvidia hat es bis heute immer geschaft fehlende Features intern zu ersetzen mit alternativen ohne relevant spürbare Verluste, teils mit Optimierungsprogrammen direkt bei den Entwicklern selbst und wenn die nicht fähig genug waren oder zu viel Zeitdruck im Spiel via Treiberoptimierung nachträglich ;)

[deekey777]

Ich bin mir nicht so sicher, ob DirectX 12 wirklich das Rennen gewinnt gegen Vulkan. Vulkan hat den großen Vorteil, dass es auf Windows 7/8 läuft. Die Installationsbasis ist viel größer.
Eigentlich hört man solche Aussagen zu jeder neuen OpenGL-Version seit 3.x und spätestens seit 4.0.

[tdon]

Bei OpenCL ist es noch schlimmer. NVidia scheißt drauf und kümmert sich lieber um CUDA und bremst damit alle. AMDs Treiber sind zwar aktuell aber buggy/wählerisch und Intel liefert aktuell nur CPU Unterstützung und _sehr_ buggy GPU Unterstützung. In Kurz: Unbenutzbar.



Intel liefert nur CPU Unterstützung? Dann hast du was verpasst. Und inwiefern buggy?

[Ganon]

Intel liefert nur CPU Unterstützung? Dann hast du was verpasst. Und inwiefern buggy?

Und du hast nicht richtig gelesen ;) Nur CPU und buggy GPU.

Buggy GPU Unterstützung weil kaum ein größeres OpenCL-Projekt (Blender, Luxrender, ...) mit dem Intel-GPU-Treiber bei mir funktioniert. Auch bei anderen Projekten ließt man oft nur OpenCL in Verbindung mit Nvidia oder AMD. Bei Intel steht dann meist: "Too buggy".

[tdon]

Und du hast nicht richtig gelesen ;) Nur CPU und buggy GPU.

Buggy GPU Unterstützung weil kaum ein größeres OpenCL-Projekt (Blender, Luxrender, ...) mit dem Intel-GPU-Treiber bei mir funktioniert. Auch bei anderen Projekten ließt man oft nur OpenCL in Verbindung mit Nvidia oder AMD. Bei Intel steht dann meist: "Too buggy".


Bei dir. Mit welcher CPU und Treiber? Gibt es dazu Quellen zum Nachlesen? Alles was ich bis jetzt probiert habe, hat funktioniert.

Vermutlich ist oft die Bereitschaft auf Intel zu optimieren ein Problem. So gut wie kein Dev testet auf einer Intel iGPU. Bei Nvidia und AMD können so Probleme schon im Vorfeld während der Entwicklung ausgeräumt werden, Intel dagegen ist auf sich alleine gestellt. Intel ist sehr aktiv im Bereich OpenCL, afaik gab es den ersten GPU fähigen OpenCL 2.0 Treiber von Intel noch vor AMD. Auch für Vulkan zeigt Intel schon lauffähige Demos.

[Ganon]

Bei dir. Mit welcher CPU und Treiber? Gibt es dazu Quellen zum Nachlesen? Alles was ich bis jetzt probiert habe, hat funktioniert.

Siehe Signatur (Core i7-4750HQ) und immer aktueller Treiber. Und soweit ich weiß ist der GPU-Treiber von Intel noch OpenCL 1.2. 2.0 hat nur der CPU-Treiber.

Und die Beispiele habe ich doch genannt. Blender Cycles mit OpenCL -> Kernel kompiliert nicht, oder LuxRender (nicht LuxMark!) einfach mal eine Szene. Entweder kompiliert sie nicht oder das Ergebnis ist Müll.

Alles Sachen die du auch gerne mal testen kannst. Kannst auch gerne deine Programme nennen.

Und das "ist halt nicht für Intel entwickelt/getestet" ist kein Argument, da in beiden Fällen das Ganze sowohl bei NVidia, AMD als auch dem CPU OpenCL Treiber von Intel funktioniert.