Diskussion zu nVidias Gameworks Programm und dessen Auswirkungen

[Schnoesel]

http://www.pcgameshardware.de/Nvidia-Geforce-Grafikkarte-255598/Specials/Nvidia-Mantle-Konter-Wundertreiber-im-April-1115532/

Nvidia versprach unlängst, einen Treiber zu veröffentlichen, der den Overhead unter DX11 verringern und damit die Performance wesentlich erhöhen soll. Angeblich könne man damit sogar Mantle schlagen. Nun gaben die Kalifornier bekannt, diesen Wundertreiber als Version 337.xx noch im April auszuliefern. Natürlich hielt man auch hauseigene Benchmarks nicht hinterm Berg, die die Konkurrenz in Gestalt von AMD naheliegenderweise recht blass erscheinen lassen.

Um dieses Ergebnis zu erreichen, setzt Nvidia auf einen "Tiled Resources"-Ansatz, der in stärkerer Form auch in AMDs Mantle-API zum Einsatz kommt. Nvidia wendet diesen jedoch unter DX11 an und will den CPU-Overhead dort angeblich signifikant verringern. Dies soll einen Low-Level-Zugriff ohne Änderungen an der API selbst ermöglichen.

Nein das ist keine Reaktion, nur das Gleiche was mantle macht den CPU Overhead zu reduzieren. Vor Mantle hat niemand auch nicht Nvidia von CPU Overhead gesprochen. Aber ist natürlich alles so gewollt gewesen, schon immer. Auch die Fachredaktionen haben das als Reaktion gewertet.
Wo sind deine Belege?

[dargo]

Das wussten wir damals doch schon:

Weil NVIDIA das nicht braucht, um ihre Grafikperformance auf die Straße bzw. in das Spiel zu kriegen.

Du wusstest damals schon, dass bsw. Maxwell nichts mit Async Compute anfangen kann? Interessant. Da kannst du mal sehen wie rückständig Nvidia bei den Features ist was moderne APIs angeht.

STAR WARS BATTLEFRONT.

Das nutzt sogar viel Tesselation für Umgebung und auch Vegetation. Dadurch haben Bäume sehr viel mehr Details und das Gute ist das der Übergang, wann und vie viel es genutzt wird, bei einer Annäherung an das Objekt flüssig verläuft. Es ist kein sichtbarer LOD Sprung. Es ist wie aus einem Guss. Werde später dazu ein Video machen.

Tesselation ist einer der besten Effekte die es gibt!
Mit welchen Faktoren arbeitet DICE dort? Mir wäre neu, dass GCN in diesem Spiel schlecht performt.

Wow, sind die bei NVIDIA flott.

Mantle wurde am 1. Februar 2014 veröffentlicht und als Reaktion hat NVIDIA nur zwei Monate später den Wundertreiber fertig. Nicht schlecht!

Ohne jetzt das Datum geprüft zu haben. Wie kommst du auf die absurde Idee der Veröffentlichungstag von Mantle wäre das erste Mal wo Nvidia was davon erfahren hat?

[Bucklew]

Wo sind deine Belege?
Brauche ich nicht, weil ich nichts behauptet habe :biggrin:

Du aber behauptest, der Treiber wäre eine Reaktion auf Mantle. Und dafür hast du bisher exakt null Belege geliefert.

Es ist schlicht und ergreifend unrealistisch, dass dieser Treiber und auch DX12 eine Reaktion auf Mantle gewesen sein soll. Dafür sind die Zeiträume viel zu kurz.

Du wusstest damals schon, dass bsw. Maxwell nichts mit Async Compute anfangen kann? Interessant.
Es gab im Feburar 2014 schon Maxwell-Karten zu kaufen? Interessant.

[Hübie]

Schon mal überlegt dass man kein Interesse an DICE hatte weil es schon längst in der Pipeline war? :rolleyes: Statt bei einem Spiel steht man gleich bei allen gut dar und bindet den Devs nicht noch mehr Arbeit auf (plus man kann seine Geheimnisse bewahren).
Ich vermag nicht zu beurteilen, ob man in so kurzer Zeit das auf die Beine stellen kann...

[Bucklew]

Ich vermag nicht zu beurteilen, ob man in so kurzer Zeit das auf die Beine stellen kann...
Natürlich nicht, passt aber sehr gut in das eigene Narrativ.

DX12 sollte ja auch nach der Propagandaabteilung eine Reaktion auf Mantle sein, tatsächlich hat hinterher NVIDIA gesagt, dass die Gespräch vier Jahre früher begannen, die Entwicklungsarbeit dahinter ein Jahr vorher. Tolle "Rekation" ;D

Übrigens auch so eine tolle AMD-"Wahrheit":
But there will be no DirectX 12. That's it.
https://www.heise.de/newsticker/meldung/AMDs-Vice-President-im-Gespraech-Es-wird-kein-DirectX-12-kommen-1835338.html

Wahrscheinlich war man da nur angepisst, weil Microsoft tatsächlich mit DX12 angefangen hatte und somit Mantle tot war.

[dargo]

Es gab im Feburar 2014 schon Maxwell-Karten zu kaufen? Interessant.
Du bist echt putzig. :tongue: Maxwell kam etwas später, das spricht also noch mehr gegen Nvidia für die miese AC Implementierung.

[Jupiter]

Mit welchen Faktoren arbeitet DICE dort? Mir wäre neu, dass GCN in diesem Spiel schlecht performt.

1. Woher soll ich die kennen?
2. Das behauptete ich auch nicht. Es lief damals (2015) in Benchmarks auf AMD Karten sogar etwas besser. Ob das heute noch der Fall ist weiß ich nicht.

[Bucklew]

Du bist echt putzig. :tongue: Maxwell kam etwas später, das spricht also noch mehr gegen Nvidia für die miese AC Implementierung.
Warum sollte NVIDIA auch AC implementieren müssen? Sie bekommen ihre Rechenleistung ja spielend auf die Straße, AMD hat doch das Problem mit 30% mehr Rechenleistung nichts anfangen zu können, außer den Rechner aufzuheizen ;D

[Gimmick]

Hat hier denn niemand einen Nvidia Developer Account und könnte in der UE4 fix einen nvidia Flex Benchmark zusammenkloppen? :D

Auf youtube gibt es nur Videos und Downloads mit älteren Flex Versionen :<

[dargo]

1. Woher soll ich die kennen?
2. Das behauptete ich auch nicht. Es lief damals (2015) in Benchmarks auf AMD Karten sogar etwas besser. Ob das heute noch der Fall ist weiß ich nicht.
Dann können das jedenfalls keine sehr hohen Faktoren sein, darum gings mir.

[dargo]

Warum sollte NVIDIA auch AC implementieren müssen?
Warum tun sie das dann bei Pascal scheibchenweise? :rolleyes:

Schon mal überlegt dass man kein Interesse an DICE hatte weil es schon längst in der Pipeline war? :rolleyes:
Schon mal überlegt, dass das was man eventuell in der Pipeline hatte bis heute nicht überall ausreichend ist, zb. im CPU-Limit? Frag mal dildo, er kann dir ein Lied mit seinem damaligen Bulldozer davon singen.

[Bucklew]

Warum tun sie dann dann bei Pascal scheibchenweise? :rolleyes:
Weißt du doch: Damit es zumindest nicht langsamer wird, wenn ein Dev das Feature nutzen will. So kann er sich zwei Codepfade sparen :rolleyes:

Große Sprünge sind eben nicht zu erwarten bei NVIDIA, weil im Gegensatz zu AMD die Shader damit beschäftigt sind, wozu sie bei einer Grafikkarte ja eigentlich gedacht sind: Grafik rendern.

ASync Compute ist nur eine Krücke, um die brachliegende Rechenleistung noch nutzen zu können, mehr nicht.

[Rancor]

Warum tun sie das dann bei Pascal scheibchenweise? :rolleyes:

Checklistenfeature, damit Sie sagen können, das sie es auch unterstützen. Bringt nur eben nix bei NV

Es ist aber auch leider eine Tatsache das Nvida auf die LL Apis noch nicht angewiesen ist um ihre TFlops auf den Bildschirm zu bringen und auch gegen VEGA brauchen sie sich in der Hinsicht nicht ins Hemd machen, leider.

Nv tut stets nur das nötigste. Wird LL mal wirklich relevant, dann wird NV auch mit dabei sein.

Solange Sie AMD mit Pascal und High Level APIs in Schach halten können, wird da nicht mehr viel passieren. Deshalb wird Volta für Gamer wohl auch erst nächstes Jahr kommen ( Achtung Sepkulatius ! )

Es ist ähnlich wie Intel. Die haben auch erst reagiert als AMD sie mit Ryzen überrumpelt hat.

[dargo]

Weißt du doch: Damit es zumindest nicht langsamer wird, wenn ein Dev das Feature nutzen will. So kann er sich zwei Codepfade sparen :rolleyes:

Kann er nicht, denn damit müsste er alle Maxwell/Kepler Besitzer komplett ignorieren.

Checklistenfeature, damit Sie sagen können, das sie es auch unterstützen.
Das hatten die schon bei Maxwell behauptet.

[Rancor]

Das hatten die schon bei Maxwell behauptet.

Stimmt, deshalb sage ich ja Checklistenfeature.

[Troyan]

Erstmal zeig du mir wo Nvidia im GPU-Limit 33% mit DX12 gegenüber DX11 zulegt. ;D

Das kannst du wohl nicht meinen.
https://www.youtube.com/watch?v=4Dv-8uQNKhY

Wenn ich mit DX12 ins GPU-Limit komme und bei DX11 im CPU-Limit verharre, gilt das dann auch? :cool:

Du sollst einfach erklären, wieso DX12 in Deus Ex im CPU-Limit 33%+ an Leistung auf einer nVidia-Karte kostet, wenn DX12 in Tomb Raider 33%+ an Leistung für das Erreichen eines GPU-Limits erreichen kann.

Damit nehme ich meinen Teil mit "lass es" zurück. Du musst ja das Wissen über die Programmierung haben. Immerhin weißt du, dass Nixxes ohne Unterstützung von nVidia und ohne Wissen der Architektur eine 33% Leistungssteigerung erreicht hat.

[dargo]

Wenn ich mit DX12 ins GPU-Limit komme und bei DX11 im CPU-Limit verharre, gilt das dann auch? :cool:

Nein, beide Szenarien sollten gpu-limitiert sein.

[Gimmick]

Du sollst einfach erklären, wieso DX12 in Deus Ex im CPU-Limit 33%+ an Leistung auf einer nVidia-Karte kostet, [...]


Dem Benchmark von CB (https://www.computerbase.de/2016-09/deus-ex-patch-dx12/#diagramm-directx-12-nach-dem-ersten-patch-core-i7-6700k) nach mit dem ersten Patch nach DX12, kostet DX12 auf jeder GPU in 720p Leistung. Wurde zwar besser, aber immernoch nicht gut.
Zudem zeigt der Benchmark extrem merkwürdiges Verhalten auf FX CPUs.

Sieht so aus, als wurde es schlicht und ergreifend schlecht umgesetzt.

[Skysnake]

Was vielen so geht, wie dir. Dieses Proprietäre Zeugs und rumgezanke dürft vielen ziemlich auf die Eier gehen. Genau wie die völlig überzogenen Preise, um halbwegs sinnvoll spielen zu können.

Da sind die ~400€ für 'ne "High End Konsole" ein Schnäppchen. Und viele wollen einfach nur zocken und haben auf diesen ganzen Mist keine Lust (mehr)...
Man wird halt alt und möchte einfach nur (noch) zocken....
Ich habe mir schon öfters überlegt weine Konsolen kaufen, aber da ich eh einen PC habe und fast nur games aus dem sale zocken, da es mir zu99% egal ist wann ich sie zocke, da wegen Familie und Beruf keine ausreichende zeit für online games da ist. Denn wenn ich zocken dann will ich auch gewinnen und das verschlingt sehr viel Zeit. Ich hatte bei WOW um Eu bzw Germany Firsts gespielt. Also weiß ich wovon ich rede...

Das Problem mit Konsolen sind halt die teuren games wobei z.b. Shooter gar nicht gehen mit Controller und Suns gibt es dort auch nicht. Also viele Spiele die ich zocke. Bleibt nur noch AC usw. Berlin dafür ne Konsole? Neee...

Und dann noch die mickrigen Controller von denen mir die Hände nach einer halben Stunde bis Stunde schmerzen und ich Krämpfe in den Fingern bekomme... ne danke.

Und auf 32 Zoll wärs auch nicht so Knalle gewesen. Mal schauen ob ich mich mit dem neuen 60er noch umentscheide. Aber Frauchen will nur Mario etc zocken... Also wenn werden es wohl gleich zwei Konsolen-_-

[Kriton]

Checklistenfeature, damit Sie sagen können, das sie es auch unterstützen. Bringt nur eben nix bei NV

Es ist aber auch leider eine Tatsache das Nvida auf die LL Apis noch nicht angewiesen ist um ihre TFlops auf den Bildschirm zu bringen und auch gegen VEGA brauchen sie sich in der Hinsicht nicht ins Hemd machen, leider.

Nv tut stets nur das nötigste. Wird LL mal wirklich relevant, dann wird NV auch mit dabei sein.

Solange Sie AMD mit Pascal und High Level APIs in Schach halten können, wird da nicht mehr viel passieren. Deshalb wird Volta für Gamer wohl auch erst nächstes Jahr kommen ( Achtung Sepkulatius ! )

Es ist ähnlich wie Intel. Die haben auch erst reagiert als AMD sie mit Ryzen überrumpelt hat.

Ihr (Du und Bucklew) habt einen Denkfehler. Euer Bezugspunkt (Leistung AMD) ist falsch. Die Frage ist, wie performant könnte (nicht ist) Nvidia unter einer LL-API im Vergleich zu DX 11 sein? Es wäre sehr verwunderlich, wenn da keine Mehrleistung generiert werden könnte. Aber das bedarf naturgemäß einer ordentlichen Doku.
Nur wenn entweder die Entwickler (zufällig) perfekt auf die Nvidia-Architektur optimiert hätten (was üblicherweise nicht der Fall ist, wie wir auch an den speziellen Spieletreibern sehen) und/oder Nvidia sämtliche nicht optimalen Codebestandteile austauschen könnte/würde (was utopisch sein dürfte) hätten wir wohl kein Steigerungspotential.
Ich bezweifele, dass jemand der hier schon mal wirklich hardwarenah programmiert hat das bestreiten würde.

Was ihr also momentan beschreibt (und falsch zuordnet) ist nicht das mangelnde Potential von Nvidia bei LL, sondern die im Vergleich zu AMD höhere Optimierung bei DX 11.

[Jupiter]

Dann können das jedenfalls keine sehr hohen Faktoren sein, darum gings mir.

STAR WARS BATTLEFRONT Tesselation: https://www.youtube.com/watch?v=JIHd74o6ywE&feature=youtu.be

Die Bäume bekommen dadurch viel mehr Details (Siehe 0:12) und durch das gleichmäßige Einblenden fällt es beim Spielen nicht so sehr auf.

[IchoTolot]

Schon geil was die Engine da abliefert. :eek:=)

Das Spiel mit einer richtig guten Campaign, wird sofort gekauft. :) Multiplayer interessiert mich nicht so sehr, das ist mir zu hektisch und ich kriege da nur Wutanfälle wie bei BF1. :D

[gravitationsfeld]

ASync Compute ist nur eine Krücke, um die brachliegende Rechenleistung noch nutzen zu können, mehr nicht.
Eh? Wat? Das ergibt keinen Sinn. In einem einzigen Kernel-Instruction-Stream kann man z.B. Speicherbandbreiten-Limitiert sein und im anderne ALU-Limitiert. Ohne beide Kernel gleichzeitig auf den CUs laufen zu lassen gibt es keine Moeglichkeit die Leistung die brach liegt auszunutzen.

Nein. Es ist keine Kruecke. Selbst wenn alles optimal laeuft ist eine Queue nicht ausreichend.

[Jupiter]

Schon geil was die Engine da abliefert. :eek:=)

STAR WARS BATTLEFRONT?

Ja, es gibt nichts besseres was Optik/Performance angeht. GTX 1080 schafft auf Endor 1800p/60fps in den höchsten Einstellungen. Sieht im Video leider nur sehr matschig aus während es bei mir sehr klar ist --> Screenshots: https://flic.kr/s/aHskBAans7

[dargo]

STAR WARS BATTLEFRONT Tesselation: https://www.youtube.com/watch?v=JIHd74o6ywE&feature=youtu.be

Die Bäume bekommen dadurch viel mehr Details (Siehe 0:12) und durch das gleichmäßige Einblenden fällt es beim Spielen nicht so sehr auf.
Sieht das mit dem Morphing bei 0:25 echt so Ingame aus? :freak:

[Jupiter]

Wenn nicht direkt darauf geschaut wird fällt das beim Spielen fast nicht auf. Reichweite würde ich trotzdem gern optional erhöhen. Genug Leistung ist vorhanden.
Was mehr stören würde ist, wenn es einen Unterschied von einem Bild zum Anderen geben würde. Wenn gutes Blending bei Schatten durchgeführt wird, stören auftauchende Schatten viel weniger (Siehe The Division).

[pixeljetstream]

Du sagst das gerade so, als ob AMD alleine Mantle auf die Beine gestellt hatte. Vergiss DICE, oder besser gesagt Johan Andersson nicht dabei. Als DICE bei Nvidia angefragt haben wollte Nvidia nichts von low level wissen. Heute wissen wir alle warum.

Nein, ich beziehe mich auf das "von Mantle zu Vulkan". Mantle war proprietär und in seiner Urform praktisch nicht performant implentierbar für die anderen Hersteller, ergo kein "Standard" (was ja auch völlig okay ist). Das Design von Vulkan unterscheidet sich zum Teil signifikant, diese Arbeit ist das was einen Standard auszeichnet und ist im Kollektiv entstanden. Die Aussagen vorher klangen für mich so als wäre mit Mantle die Arbeit getan und die anderen Hersteller mussten es nur implementieren, oder das AMD sich besonder stark in diesem Prozess engagieren würde.

Das ist keine Schmälerung dessen was sie und DICE vorher gemacht haben, aber es endet eben dort nicht.

[gravitationsfeld]

Ich kann bestaetigen, dass Vulkan definitiv nicht ein AMD-Standard ist.

https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#credits
Unter anderem:
Daniel Koch, NVIDIA (Shader Interfaces; Features, Limits, and Formats)
Jeff Bolz, NVIDIA (extensive contributions, exhaustive review and rewrites for technical correctness)
Kerch Holt, NVIDIA (SPIR-V technical sub-group chair)
Piers Daniell, NVIDIA (dynamic state, copy commands, memory types)

Die meisten Extensions in letzter Zeit kommen auch aus NVIDIA-Hand.

Was aber wirklich stimmt ist, dass der Standard wohl aus der Mantle-Spec hervorgegangen ist. Viele Namen von Funktionen haben schlicht vk statt gr als Praefix, sind aber sonst sehr aehnlich wie in Mantle. Das heisst aber nicht, dass es nicht extreme Aenderungen gab fuer Portabilitaet etc.

[Kartenlehrling]

Turf und Hairworks war damals für Just Cause 3 geplant,
in die Verkaufsversion haben es dann beide nicht geschaft,
in Witcher3 hat es ja dann nur Hairworks geschaft.

Sollte die Entwicklung von Features nicht weiter gehen und versucht werden der Verbrauch an Rechenleistung zu senken und
nicht erst warten wenn die Hardware in diesem Fall eine Nvidia 1080Ti da ist? :rolleyes:


Ich würde mir ja gerne eine 1050Ti zur meinen R9nano packen wenn ich dafür alle Gameworks Featurs aktivieren könnte, aber Nvidia will es nicht.


Anscheinend war ich mit meiner Aussage sehr nah dran... :freak:
Wenigsten sieht FFxv besser aus als Agents of Mayhem das auch den Gameworks Stempel bekommen hat, wo die 1080Ti auch mit 30fps bei 4k rumkrebst.

Square Enix führt das Spiel auf Systemen mit GeForce GTX 1080 Ti in 4K-Auflösung auf der Gamescom vor.
Laut Hajime Tabata von Square Enix würde eine GTX 1080 Ti momentan gerade für 30 FPSs in dieser 4k-Auflösung genügen.
https://www.computerbase.de/2017-08/final-fantasy-xv-speicherplatz-missverstaendnis/

[Kriton]

@pixeljetstream:

Ich wollte nicht die Arbeit der Leute außerhalb von AMD hinsichtlich Vulkan herabwürdigen. Mit "aufgegangen" meine ich nur, dass es den Grundstein gelegt und damit die Basis gebildet hat und danach nicht mehr eigenständig weitergeführt wurde.

Edit: Vielleicht auch noch eine Erinnerung an den Kontext: Es war ja als Gegenposition zu der Aussage gemeint, dass AMD mit Mantle ebenfalls proprietär sei (Präsenz!).

[Schaffe89]

AMD bleibt aber auch bald nichts andere mehr übrig als LL zu pushen und Ihre stärken direkt bei den Entwicklern einzubringen....

Mich freuts dass Nvidia wieder verstärkt den PC gegenüber der Konsole aufwertet. Hairworks, Godrays, HBOA+, Schatten etc. sind doch ein gutes Engagament, solange es optional als AMD Nutzer deaktiviert werden kann.

Den Beleg dass Nvidia AMD mit diesen Features ausbremsen will, den ist man bisher immernoch schuldig geblieben.

weil diese die Leistung soweit verkrüppeln, dass man sich fragt wofür das als PC Exclusiv überhaupt benannt wird. Es ist eher Top GPU Exclusiv der Rest stellt sich hinten an.

Ich kann mit meiner GTX 1080/GTX 1080 Ti alles und auch damals GTX 1060 fast alles aktivieren (Godrays in Widllands+ Hairworks in The Witcher und noch gut flüssig zocken.:redface:

<- gtx 1060 & GW ist scheise so lange es durch Dinge wie die extrem hohen Tesselation Faktoren benutzt wird um die Konkurrenz richtig aus zu bremsen..

Ja schon klar, die Konkurrenz wird ausgebremst mit Gameworks.
Wo bleiben die Belege dafür? Bei den Haaren von the Witcher sieht man selbst zwischen x32 und x64 noch einen leichten Qualitätsunterschied, also ist x64 als Faktor angebracht, der auf Nvidia soviel Leistung nicht kostet, bei AMD dafür schon, was daran liegt dass es AMD seit 8 Jahren nicht schafft den Tesselator endlich zu fixen.

Denn nur weil es der Konkurrenz mehr weh tut als einem selbst heißt es nicht das es einem selbst nicht auch ziemlich weh tut.

Hairworks kostet etwa 20% auf meiner GTX 1080 in Witcher 3.
HBOA+ 5% gegenüber SSAO, verschmerzbar für den Haareffekt, bei trotzdem knapp 90 FPS in Full HD und 60 in WHQD.

Nvidia nimmt es in Kauf sich ins knie zu schießen einfach weil sie wissen das sie beide Kniee der Konkurrenz treffen...


Eine Theorie ohne Beweise, zumal abgesehen von Hairworks alle anderen Features nicht messbar schlechter auf AMD laufen.
Bei Hairworks liegts einfach an AMD´s schwachen Tesselator.

Und bezüglich amd könnte auch die hohen Tesseract Faktoren verbessern.

Du meinst die Cheat Funktion die AMD gerade im Treiber hat?
Anwendungsgesteuerte Tesselationsfaktoren einfach unterbinden?
Halte ich für ungut.

Was vielen so geht, wie dir. Dieses Proprietäre Zeugs und rumgezanke dürft vielen ziemlich auf die Eier gehen.....

Das rumgezanke kommt fast ausschließlich aus der AMD Ecke. Ich hatte noch nie etwas gegen Gameworks solange es optional ist und man es deaktivieren kann. Es verbessert wie fast nichts anderes am Markt in vielen Spielen die Optik.
Wenn es die Entwickler soviel besser könnten, dann würden sie es nicht nuzen.
Seien wir doch froh dass Nvidia einen Großteil der Gameworks Dinge auch auf AMD Hardware laufen lässt und das kaum langsamer. Teilweise kostet es sogar auf AMD Hardware weniger Performance.

Genau wie die völlig überzogenen Preise, um halbwegs sinnvoll spielen zu können.

Du meinst AMD mit ihren überzogegen Fiji und Vega Preisen?
Oder den nicht besseren P/L einer RX480 gegenüber einer GTX 1060?:rolleyes:
Der Vorwurf der hohen Preise deckt sich schon lange nicht mehr mit der Realität.

[Hübie]

Hat hier denn niemand einen Nvidia Developer Account und könnte in der UE4 fix einen nvidia Flex Benchmark zusammenkloppen? :D

Auf youtube gibt es nur Videos und Downloads mit älteren Flex Versionen :<

Hab zwar Zugang etc. aber beim besten Willen keine Zeit dafür. Glaube das ist auch nicht mal eben so gemacht oder gibt es da was fettiges, was man nur kompilieren braucht?

[DrFreaK666]

Mal eine Noob-Frage: Kann AMD-Hardware alle GW-Effekte darstellen?

edit: bis auf the division (Die einzige Option, welche wir auf der zweitbesten Stufe stehen lassen mussten, ist die Schattenfilterung. Hier testen wir mit dem Verfahren PCSS+, da die Maximalstufe HFTS nur auf Maxwell-2.0-Grafikkarten angeboten wird und daher keine vergleichbaren Werte zwischen Radeon und Geforce möglich sind.) finde ich keine Beispiele.
Sollte es wirklich so sein, dann finde ich GW weniger schlimm :)

[Hübie]

Nein. Iirc kein HFTS. Bei dem fehlt es der Hardware an Features (Conservative Rasterization und noch irgendwas - GS Passthrough?).
VXAO ist auf Kepler und AMD ebenfalls wenig performant weil da was fehlt, aber hab vergessen was das war. :D

[Gimmick]

Hab zwar Zugang etc. aber beim besten Willen keine Zeit dafür. Glaube das ist auch nicht mal eben so gemacht oder gibt es da was fettiges, was man nur kompilieren braucht?

Ich weiß nicht was da alles bei ist.
https://forums.unrealengine.com/development-discussion/content-creation/118111-flex?145171-Flex=

Wäre auch gut möglich, dass da eine lauffähige Demo bei ist. Ob man die teilen darf müsste in der Lizenz stehen.
Bei den älteren Versionen konnte man die Demo zumindest einfach runterladen.

[Bucklew]

Ihr (Du und Bucklew) habt einen Denkfehler. Euer Bezugspunkt (Leistung AMD) ist falsch. Die Frage ist, wie performant könnte (nicht ist) Nvidia unter einer LL-API im Vergleich zu DX 11 sein? Es wäre sehr verwunderlich, wenn da keine Mehrleistung generiert werden könnte. Aber das bedarf naturgemäß einer ordentlichen Doku.
Die Sache ist doch ganz einfach: NVIDIA ist in DX11 sehr stark. Sie können ihre Grafikkarte schon mit DX11 sehr gut auslasten (Vergleiche hierzu die "Papierleistung" von AMD/NVIDIA vs. tatsächlicher Gamingleistung).

Dass da also mit LL viel Performance brach liegt, ist unwahrscheinlich. Wo sollte sie her kommen? 8,8 TFlops bleiben eben 8,8 TFlops und nur wenn unter DX11 nur 8 TFlops genutzt werden, könnte LL unter perfekter Ausnutzung der Ressourcen z.B. 10% Mehr Shaderperformance liefern (Vorsicht! Beispiel!)

Nur wenn entweder die Entwickler (zufällig) perfekt auf die Nvidia-Architektur optimiert hätten (was üblicherweise nicht der Fall ist, wie wir auch an den speziellen Spieletreibern sehen) und/oder Nvidia sämtliche nicht optimalen Codebestandteile austauschen könnte/würde (was utopisch sein dürfte) hätten wir wohl kein Steigerungspotential.
Ich bezweifele, dass jemand der hier schon mal wirklich hardwarenah programmiert hat das bestreiten würde.
Ach so. Also die Entwickler, die in Vielzahl nicht mal das abstrahierte DX11 hin bekommen, sollen jetzt plötzlich LL können? Und das ganze auch noch perfekt skaliert auf mindestens 2 völlig unterschiedlichen Architekturen mit nochmal mindestens jeweils 3 Architektur-Iterationen?

Sorry, ich glaube nicht an den Weihnachtsmann.

Ich denke, für den Großteil der Entwickler (>90%) ist es sinnvoller, auf die sehr gut ausgetretenen DX11-Pfade der IHVs zu laufen, als selbst rumzufummeln.

Ich erinnere an die Probleme von DICE mit Mantle und der "neuen" R9 285:
http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/News/AMD-Mantle-R9-Fury-X-R9-380-GCN-12-1163442/

Was ihr also momentan beschreibt (und falsch zuordnet) ist nicht das mangelnde Potential von Nvidia bei LL, sondern die im Vergleich zu AMD höhere Optimierung bei DX 11.
Das Potential von NVIDIA bei LL ist einfach geringer, als bei AMD.

Eh? Wat? Das ergibt keinen Sinn. In einem einzigen Kernel-Instruction-Stream kann man z.B. Speicherbandbreiten-Limitiert sein und im anderne ALU-Limitiert. Ohne beide Kernel gleichzeitig auf den CUs laufen zu lassen gibt es keine Moeglichkeit die Leistung die brach liegt auszunutzen.
Stimmt. Nur ist eben so, dass diese brach liegende Leistung bei NVIDIA viel geringer ist, als bei AMD. Schon alleine dadurch wird NVIDIA niemals den ASnyc-Vorteil haben, wie AMD.

Und: Schon mit Polaris ist der ASync-Vorteil ziemlich eingedampft worden gegenüber den Generationen vorher.

[Schnoesel]

Dein Fehler ist das du LL rein auf GPU Limit reduzierts, da magst du mit deiner Aussage recht haben, dass Nvidia hier weniger Optimierungspotential hat. Für das CPU Limit bezüglich Auslastung, Overhead, Frametimes etc. liegst du allerdings weit daneben. Zwar hat Nvidia den Treiber Overhead besser im Griff, aber an eine richtige LL Implementierung kommt das auch nicht ran. Nicht jeder hat einen OC 7700K zu Hause stehen. Auch Nvidia-Nutzer würden also von einer sauberen Implementierung von LL APIs proftieren.

[Bucklew]

Nicht jeder hat einen OC 7700K zu Hause stehen.
Nö, habe ich auch nie behauptet.

Aber wer keinen 7700k zuhause hat, der hat ebenso wenig eine GTX1080Ti.

Die Korrelation i3 + GTX1080Ti wird nahe null liegen. Und somit sind die ganzen LL-CPU-Overhead-Tests ganz nett aus technischer Sicht, für den durchschnittlichen Käufer hat es nur wenig Relevanz.

[Gimmick]

Die Korrelation i3 + GTX1080Ti wird nahe null liegen. Und somit sind die ganzen LL-CPU-Overhead-Tests ganz nett aus technischer Sicht, für den durchschnittlichen Käufer hat es nur wenig Relevanz.

Da ist der Gedanke aber auf halber Strecke liegen geblieben. :uponder:

[iuno]

Nein. Iirc kein HFTS. Bei dem fehlt es der Hardware an Features (Conservative Rasterization und noch irgendwas - GS Passthrough?).
VXAO ist auf Kepler und AMD ebenfalls wenig performant weil da was fehlt, aber hab vergessen was das war. :D
:confused:
CR kann man auch in Software machen (man macht einfach die Dreiecke vorher im GS groesser, sodass alle Pixel rasterisiert werden). So hat Nvidia das uebrigens auch urspruenglich im Paper verglichen. Ist selbstverstaendlich langsamer, geht aber trotzdem. Wenn sie wollten haetten sie also HFTS auch auf GCN und <Maxwell lauffaehig machen koennen aber offenbar hat man sich das lieber erspart.

[Kriton]

Die Sache ist doch ganz einfach: NVIDIA ist in DX11 sehr stark. Sie können ihre Grafikkarte schon mit DX11 sehr gut auslasten (Vergleiche hierzu die "Papierleistung" von AMD/NVIDIA vs. tatsächlicher Gamingleistung).

An dieser Stelle frage ich mich, ob Du meinen zitierten Post gelesen/verstanden hast. Der Vergleich Nvidia/AMD von Dir sagt mir: Nein.
Denn wenn AMD (wie von mir dargestellt) nicht als Bezugspunkt funktioniert, dann ist Deine weitere Argumentation eben darauf basierend obsolet. Du müsstest also meine Prämisse "angreifen" - was Du nicht tust. Ich bezweifele auch, dass dies (im Ergebnis) möglich ist.

Das Potential von NVIDIA bei LL ist einfach geringer, als bei AMD.

Beschreibt Dein Denken sehr gut: Nvidia muss verteidigt werden! Ich habe gar nichts dazu gesagt, wie groß das Potential ist (das kann ich gar nicht, weil mir dazu das Wissen fehlt), sondern nur argumentiert dass es da ist. Und der in diesem Kontext von mir zitierte Satz hat nichts mit deiner darauf folgenden Antwort zu tun.
Unabhängig davon: Beweis durch Behauptung? Und gleich der Disclaimer: Ich behaupte nicht, dass Du unrecht hast, nur dass wir es beide nicht wissen (bei mir weiss ich es, bei Dir vermute ich es auf Basis Deiner Antworten).

Insoweit Du auf die Schwierigkeiten für Entwickler eingehst: Das war nicht mein Punkt, sondern die prinzipielle (objektive) Möglichkeit.

[Bucklew]

Da ist der Gedanke aber auf halber Strecke liegen geblieben. :uponder:
Warum?

An dieser Stelle frage ich mich, ob Du meinen zitierten Post gelesen/verstanden hast. Der Vergleich Nvidia/AMD von Dir sagt mir: Nein.
Denn wenn AMD (wie von mir dargestellt) nicht als Bezugspunkt funktioniert, dann ist Deine weitere Argumentation eben darauf basierend obsolet. Du müsstest also meine Prämisse "angreifen" - was Du nicht tust. Ich bezweifele auch, dass dies (im Ergebnis) möglich ist.
Wenn du keinen Vergleich mit AMD zulässt, dann ist eine Diskussion völlig sinnlos.

Oder benenne mir bitte die durchschnittliche Auslastung einer NVIDIA-Karte in den sagen wir mal 10 verbreitesten DX11-Spielen. Und erst dann können wir anfangen, über den Nutzen von LL zu diskutieren.

Beschreibt Dein Denken sehr gut: Nvidia muss verteidigt werden!
Nö. Aber wenn man keine Argumente hat, dann muss man die Argumente des gegenüber per hominem-Argument zerstören. Leicht zu machen - leicht zu durchschauen.

Ich habe gar nichts dazu gesagt, wie groß das Potential ist (das kann ich gar nicht, weil mir dazu das Wissen fehlt), sondern nur argumentiert dass es da ist. Und der in diesem Kontext von mir zitierte Satz hat nichts mit deiner darauf folgenden Antwort zu tun.
Das riecht nach Trolllogik. Du weiß nicht, wie groß das Potential ist, weißt aber, dass es da ist.

Das ergibt keinen Sinn.

S.O.: Bitte benenne die durchschnittliche Auslastung einer Pascal-Grafikkarte in den Top10 DX11-Spielen.

Du behauptest, es sei Potential da, dann musst du diese Frage spielend beantworten können.

Unabhängig davon: Beweis durch Behauptung? Und gleich der Disclaimer: Ich behaupte nicht, dass Du unrecht hast, nur dass wir es beide nicht wissen (bei mir weiss ich es, bei Dir vermute ich es auf Basis Deiner Antworten).
Bullshit. Dass NVIDIA bei geringerer Papierleistung eine höhere und/oder identische Gamingleistung bringt, belegen hunderte von Benchmarks.

Ob bei NVIDIA in DX11 Potential bracht liegt, das wissen wir nicht.

Das erste ist meine Behauptung, die zweite deine.

Insoweit Du auf die Schwierigkeiten für Entwickler eingehst: Das war nicht mein Punkt, sondern die prinzipielle (objektive) Möglichkeit.
LL-API bedeuten mitnichten eine Performancesteigerung.

Beleg: Ein Haufen aktueller DX12-Titel.

[pixeljetstream]

Du meinst die Cheat Funktion die AMD gerade im Treiber hat?
Anwendungsgesteuerte Tesselationsfaktoren einfach unterbinden?
Halte ich für ungut.

Imo ist das "fair", es ist jedem Hersteller selbst überlassen was er da freischaltet. Finde ich eigentlich nen cleveren Schachzug, solange sowas nicht intern gemacht sondern für den Anwender sichtbar ist, ist's vertretbar.

[dargo]

Die Sache ist doch ganz einfach: NVIDIA ist in DX11 sehr stark. Sie können ihre Grafikkarte schon mit DX11 sehr gut auslasten (Vergleiche hierzu die "Papierleistung" von AMD/NVIDIA vs. tatsächlicher Gamingleistung).

Wo ist die überlegene DX11 Leistung von Nvidia in bsw. Resident Evil 7 geblieben?
http://www.pcgameshardware.de/Resident-Evil-7-Biohazard-Spiel-57353/Specials/Benchmark-PC-Anforderungen-1219005/

EVGA 1070 @1924Mhz = 7,39 TFLOPs
Asus R9 390 @1050Mhz = 5,38 TFLOPs

Pascal hat hier 37% mehr TFLOPs als Grenada und ist nur 17% schneller, in 1440p sogar nur 14%.

[aufkrawall]

Und würde es mit DX12 dann auf NV schneller laufen? Wohl kaum. Was ist dein Punkt, falls es den gibt?

[dargo]

Eigentlich ist glasklar mein Punkt, du musst nur lesen. Ein weiteres Beispiel wäre CoD: Infinite Warfare. Wo ist da nochmal Nvidia so überlegen (Papierleistung vs. Gamingleistung)?
https://www.youtube.com/watch?v=07ZA7o_y0JM

Oh Wunder... wieder nur ein DX11 Titel. Hätten beide Titel einen DX12 Renderer inkl. AC und am besten noch Shader Intrinsics , würde es höchstwahrscheinlich noch schlimmer für NV aussehen.

[Gimmick]

Warum?


Weil aus der Schnittmenge i3 & 1080ti nichts in der Richtung folgt.
Weil Du gegen geschenkte Leistung argumentierst.
Weil du nicht den Vorteil bei zukünftigen Entwcklungen siehst.
Usw.


Oder benenne mir bitte die durchschnittliche Auslastung einer NVIDIA-Karte in den sagen wir mal 10 verbreitesten DX11-Spielen. Und erst dann können wir anfangen, über den Nutzen von LL zu diskutieren.


"Auslastung" wie in den OSDs zeigt das nicht.


Du behauptest, es sei Potential da, dann musst du diese Frage spielend beantworten können.


Es ist immer Potential da.


LL-API bedeuten mitnichten eine Performancesteigerung.

Beleg: Ein Haufen aktueller DX12-Titel.

Nicht automatisch das ist klar.
Aber weil das nicht so einfach ist direkt kategorisch den Nutzen absprechen... das ist total kurzsichtig.

Wenn Du sagen willst "momentan profitiert nV nicht von LL APIs" - von mir aus.

Aber Du profitierst von LL APIs.

[Bucklew]

Wo ist die überlegene DX11 Leistung von Nvidia in bsw. Resident Evil 7 geblieben?
Mmmmmh..... lecker Kirschen! Du hast du aber schön gepflückt! ;D

Weil aus der Schnittmenge i3 & 1080ti nichts in der Richtung folgt.
Weil Du gegen geschenkte Leistung argumentierst.
Weil du nicht den Vorteil bei zukünftigen Entwcklungen siehst.
Usw.
Weder noch. Bitte lies nochmal mein Posting, verstehe was ich gesagt habe und versuche es dann nochmal.

Tipp in der Richtung: Wo wird mir wohl mehr Leistung "geschenkt"? Wenn NVIDIA ihren Treiber nur noch für die paar DX12 Spiele optimieren würde, oder wenn sie wie jetzt für die zig Tausenden DX11 Spiele optimiert?

"Auslastung" wie in den OSDs zeigt das nicht.
Woher wisst ihr denn dann, dass da soviel Leistung bei NVIDIA raus zu holen wäre?

Es ist immer Potential da.
Warum könnt ihr das Potential dann nicht belegen?

Und warum gibt es dann so viele Spiele mit HL und LL API und die HL API läuft viel besser?

Nicht automatisch das ist klar.
Aber weil das nicht so einfach ist direkt kategorisch den Nutzen absprechen... das ist total kurzsichtig.
Gut das ich nicht kurzsichtig bin. Denn ich spreche den Nutzen gar nicht kategorisch ab ;D

Wenn Du sagen willst "momentan profitiert nV nicht von LL APIs" - von mir aus.
Tue ich nicht, nein.

Aber Du profitierst von LL APIs.
Auch das tue ich in 99,9999% der Spielen nicht.

Weil die gar keine LL API unterstützen.

[Kriton]

Für die Frage ob bei Nvidia durch LL gegenüber DX 11 Leistung zu erhalten ist, ist ein Vergleich mit AMD irrelevant.
Wenn dies bereits nicht verständlich ist, dann tun wir beide uns schwer für eine weitere Diskussionsbasis.

Ansonsten kannst Du versuchen mir zu erklären wie Du darauf kommst, dass die Umsetzung einer Prozedur auf einem gegebenen System in einer Hochsprache prinzipiell nicht effizienter in Assembler (mir ist klar, dass wir hier im konkreten Fall nicht über Assembler reden - es geht nur um das Prinzip) programmiert werden kann.
Das würde IMHO voraussetzen, dass der Compiler (bezogen auf das System auf dem der Code laufen soll) in jedem Anwendungsfall grundsätzlich perfekten Code erzeugt. Das ist... unwahrscheinlich.

Ich behaupte nicht, dass es für Nvidia effizient wäre, oder dass viel herauszuholen wäre (wie bereits gesagt, verfügen wir vermutlich beide nicht über das notwendige Wissen um das beurteilen zu können), aber dass es prinzipiell möglich ist: Das würde ich demzufolge schon sagen.

Edit: Dein Vorwurf des ad hominem: Es geht mir darum, dass Dein Post (der auf den ich hier antworte übrigens auch) nach meiner Wahrnehmung stark in Richtung der Verteidigung von Nvidia geht. Ich greife sie aber gar nicht an, sondern beschreibe ein grundlegendes Prinzip, dass eben auch auf Nvidia Anwendung findet. Das scheinst Du fälschlicherweise als Angriff auf Nvidia verstanden zu haben - darauf habe ich mich bezogen.

[Schnoesel]

Die Korrelation i3 + GTX1080Ti wird nahe null liegen.

Hä wer hat den von dieser Zusammenstellung gelabert. Du kannst auch mit einer 1060 im CPU Limit sein kommt ganz auf das Spiel an. Schau die die Softwarekrücke PUBG an, die ist quasi dauernd CPU limitiert.

[Bucklew]

Für die Frage ob bei Nvidia durch LL gegenüber DX 11 Leistung zu erhalten ist, ist ein Vergleich mit AMD irrelevant.
Wenn dies bereits nicht verständlich ist, dann tun wir beide uns schwer für eine weitere Diskussionsbasis.
Wer bist du denn? ;D

Ich darf doch wohl selbst wählen, welches Argumente ich hier vorbringe oder nicht. Und wenn der Vergleich mit AMD eben belegt, dass das Potential bei NVIDIA gar nicht so groß sein kann, wie bei AMD, warum sollte ich das dann nicht vorbringen? Nur weil du es nicht widerlegen kannst und bisher 0 (in Worten: null) Belege für deine Behauptung gebracht hast? ;D

Ansonsten kannst Du versuchen mir zu erklären wie Du darauf kommst, dass die Umsetzung einer Prozedur auf einem gegebenen System in einer Hochsprache prinzipiell nicht effizienter in Assembler (mir ist klar, dass wir hier im konkreten Fall nicht über Assembler reden - es geht nur um das Prinzip) programmiert werden kann.
Das würde IMHO voraussetzen, dass der Compiler (bezogen auf das System auf dem der Code laufen soll) in jedem Anwendungsfall grundsätzlich perfekten Code erzeugt. Das ist... unwahrscheinlich.
Du solltest dich mal grundsätzlich mit der Codeentwicklung, Assemblern, Compilern und speziell Codeoptimierung beschäftigen.

Nur weil man mit Assemblern den (theoretisch) am besten optimierten und daher schnellsten Code programmieren kann, heißt dies noch lange nicht, dass das auch 100% aller Programmier schaffen.

Und hier ist der Krucks. Die Erfahrung, Man-Power und Schluss endlich Zeit und Geld, die investiert werden muss, damit LL Code (egal ob auf CPU oder GPU) besser ist, als das, was automatisiert erzeugt wird (egal ob durch einen Compiler oder durch einen GPU-Treiber), steht fast immer in keinem Verhältnis zur erreichten Mehrperformance.

Oder erkläre mir doch mal, wenn doch LL der heilige Gral ist und da ja ach so viel Performance brach liegt bei NVIDIA - warum schafft es dann nicht mal DICE (sicherlich eine der Top-Adressen weltweit, was Grafikengine-Entwicklung angeht) einen performanten DX12-Port hinzukriegen in BF1?

Ich behaupte nicht, dass es für Nvidia effizient wäre, oder dass viel herauszuholen wäre (wie bereits gesagt, verfügen wir vermutlich beide nicht über das notwendige Wissen um das beurteilen zu können), aber dass es prinzipiell möglich ist: Das würde ich demzufolge schon sagen.
Wieso wäre es für NVIDIA "effizient"? Effizient wäre nur, dass die Arbeit vom IHV zu den Entwicklern wandert. Und nun fragen wir uns doch mal ganz still und leise im Innern, warum wohl AMD so ein Interesse an LL hat? :biggrin:

Edit: Dein Vorwurf des ad hominem: Es geht mir darum, dass Dein Post (der auf den ich hier antworte übrigens auch) nach meiner Wahrnehmung stark in Richtung der Verteidigung von Nvidia geht. Ich greife sie aber gar nicht an, sondern beschreibe ein grundlegendes Prinzip, dass eben auch auf Nvidia Anwendung findet. Das scheinst Du fälschlicherweise als Angriff auf Nvidia verstanden zu haben - darauf habe ich mich bezogen.
Ich habe es überhaupt gar nicht als Angriff auf irgendeinen IHV verstanden ;D Mir scheint hier, du bist zu sehr in deiner Gedankenwelt mit IHV vs. IHV verhaftet. Das darfst du gern sein, aber bitte projiziere dies nicht auf mich. Damit disqualifizierst du dich nur als Diskussionspartner.

Dass du auf meinen sachlichen Kommentar, dass aufgrund des Vergleichs von Papierleistung vs. realer (Gaming-)Leistung bei sowohl AMD als auch NVIDIA geschlossen werden kann, dass das brach liegende Potential von NVIDIA deutlich geringer bzw. eventuell sogar gar nicht vorhanden ist, nur antworten kannst, da würde ich NVIDIA verteidigen "müssen" - das ist sicherlich keine Glanzstunde der Diskussionskultur, im Gegenteil.

Hä wer hat den von dieser Zusammenstellung gelabert. Du kannst auch mit einer 1060 im CPU Limit sein kommt ganz auf das Spiel an. Schau die die Softwarekrücke PUBG an, die ist quasi dauernd CPU limitiert.
Na du hast den Zusammenhang hergestellt. Du hast behauptet nicht jeder hätte einen 7700k übertaktet. Was sollen die Leute denn sonst haben, wenn keinen i7? Einen PentiumIII?

Wie viel schneller ist PUBG denn unter DX12? Oder Vulkan?

[Schnoesel]

Der einzige der Zusammenhänge aus dem Nichts bildet bist du nicht ich. Da ist mir die Zeit echt zu schade...

[Bucklew]

Der einzige der Zusammenhänge aus dem Nichts bildet bist du nicht ich. Da ist mir die Zeit echt zu schade...
Du hast offensichtlich nicht verstanden, was ich sagen will.

Es mag nicht jeder einen 7700k OC haben - nur wer wirklich CPU-bound ist, weil ne fette High-End Karte drin hat, der wird sehr wahrscheinlich so eine CPU (oder noch schneller) besitzen.

Nennt sich balanced PC. Niemand kombiniert einen i3 mit einer TitanX.

PS: Wie hoch ist denn nun der Performancevorteil vom PUBG DX12-Port? Das hast du leider nicht nicht beantwortet :(

[Blediator16]

Du hast offensichtlich nicht verstanden, was ich sagen will.

Es mag nicht jeder einen 7700k OC haben - nur wer wirklich CPU-bound ist, weil ne fette High-End Karte drin hat, der wird sehr wahrscheinlich so eine CPU (oder noch schneller) besitzen.

Nennt sich balanced PC. Niemand kombiniert einen i3 mit einer TitanX.

PS: Wie hoch ist denn nun der Performancevorteil vom PUBG DX12-Port? Das hast du leider nicht nicht beantwortet :(

Die Frage ist eher ob die Devs überhaupt auf Vulkan bzw. DX12 aufspringen wollen. Das Spiel wird noch einige Monate gemolken und ab zum nächsten One Hit Wonder.

[Hübie]

:confused:
CR kann man auch in Software machen (man macht einfach die Dreiecke vorher im GS groesser, sodass alle Pixel rasterisiert werden). So hat Nvidia das uebrigens auch urspruenglich im Paper verglichen. Ist selbstverstaendlich langsamer, geht aber trotzdem. Wenn sie wollten haetten sie also HFTS auch auf GCN und <Maxwell lauffaehig machen koennen aber offenbar hat man sich das lieber erspart.

Na, ich weiß ja nicht ob das so positiv angekommen wäre. Dann läuft's wie ein Sack Nüsse und am Ende whinen se doch alle wieder. HFTS willst du nicht mal auf Maxwell aktivieren. ;)

Imo ist das "fair", es ist jedem Hersteller selbst überlassen was er da freischaltet. Finde ich eigentlich nen cleveren Schachzug, solange sowas nicht intern gemacht sondern für den Anwender sichtbar ist, ist's vertretbar.

Ganz genau meine Meinung. Aber wie ich dir schon sagte liegt einigen mehr an ihrem Kreuzzug, als dem Gemeinwohl.
Ich kann nach wie vor keine Belege für AMDs damalig Vorwürfe finden und es ist auch relativ ruhig um das Thema geworden...

[Gimmick]

Weder noch. Bitte lies nochmal mein Posting, verstehe was ich gesagt habe und versuche es dann nochmal.

Tipp in der Richtung: Wo wird mir wohl mehr Leistung "geschenkt"? Wenn NVIDIA ihren Treiber nur noch für die paar DX12 Spiele optimieren würde, oder wenn sie wie jetzt für die zig Tausenden DX11 Spiele optimiert?


Wieso denn "oder"?
Bei der CPU wird einiges frei.


Woher wisst ihr denn dann, dass da soviel Leistung bei NVIDIA raus zu holen wäre?

Warum könnt ihr das Potential dann nicht belegen?


Weil das in der Natur der Dinge liegt. Es gibt kein perfektes System.
Und zumindest ich beziehe mich nicht nur auf GPUs.


Und warum gibt es dann so viele Spiele mit HL und LL API und die HL API läuft viel besser?


Weil es neu und nicht einfach ist.


Gut das ich nicht kurzsichtig bin. Denn ich spreche den Nutzen gar nicht kategorisch ab ;D

Tue ich nicht, nein.

Auch das tue ich in 99,9999% der Spielen nicht.

Weil die gar keine LL API unterstützen.

Hä?
Profitierst auch nicht von doppelten FP16 Einheiten, neuen Gameworks Effekten, CPUs mit mehr Kernen usw., weil das jetzt noch nicht genutzt wird.
Nennt sich Fortschritt.

Einige moderne Spielen treiben heutige CPUs an ihre Grenze. Die IPC-Steigerung pro Generation wird immer geringer. Einige Entwickler meinten in Interviews, dass mit LL APIs deutlich besseres Multithreading möglich sein wird.

Sehe nicht warum das nicht gut sein soll.

[dargo]

Oder erkläre mir doch mal, wenn doch LL der heilige Gral ist und da ja ach so viel Performance brach liegt bei NVIDIA - warum schafft es dann nicht mal DICE (sicherlich eine der Top-Adressen weltweit, was Grafikengine-Entwicklung angeht) einen performanten DX12-Port hinzukriegen in BF1?

Du solltest vielleicht auch mal zwischen den Zeilen hier lesen wenn sich ein Entwickler dazu äußert. Jetzt nicht speziell auf BF1 bezogen. Schlechte Dokumentation der NV-Hardware wurde öfter erwähnt.

Du hast offensichtlich nicht verstanden, was ich sagen will.

Es mag nicht jeder einen 7700k OC haben - nur wer wirklich CPU-bound ist, weil ne fette High-End Karte drin hat, der wird sehr wahrscheinlich so eine CPU (oder noch schneller) besitzen.

Nennt sich balanced PC.
Deinen "balanced PC" gibt es eben nur weil es noch so viele high level Spiele in der PC-Umgebung gibt. Ursache --> Wirkung und so.

[Schaffe89]

Eigentlich ist glasklar mein Punkt, du musst nur lesen. Ein weiteres Beispiel wäre CoD: Infinite Warfare. Wo ist da nochmal Nvidia so überlegen (Papierleistung vs. Gamingleistung)?
https://www.youtube.com/watch?v=07ZA7o_y0JM

Dein Fehler ist dass du dir eigentlich immer nur irgendwelche Kirschenbenchmarks herauspickst und das alle Nase lang.
Den Blick auf das große ganze blendest du immer aus, du wolltest sogar mal nur noch Spiele mit Vulkan/Directx12 kaufen, weil alles andere ja "Müll" sei.

Oh Wunder... wieder nur ein DX11 Titel. Hätten beide Titel einen DX12 Renderer inkl. AC und am besten noch Shader Intrinsics , würde es höchstwahrscheinlich noch schlimmer für NV aussehen.

Genau, shader intrinsics, ein AMD exclusives Feature, aber nebenbei über Gameworks herziehen.:rolleyes:
Es gab schon immer Spiele die auf einem IHV manchmal besser oder schlechter laufen aber was du machst ist der Gipfel der Kirschen.

Suche man sich aus der Hand voll Directx11 Titel die bei AMD hinsichtlich der FLOps gut laufen das beste heraus und mische noch Directx12, Async und shader intrinsics bei... ja ne is klar.

Davon mal abgesehen was hat uns die LL-API denn bisher groß gebracht? Außer Querelen quasi nichts.
AMD will sich die Treiberarbeit sparen, weil AMD darin einfach schlecht ist. Die sollten sich auf dn Hosenboden setzen und endlich mal ihren Directx11 Treiber angehen.
Was bringt es einem Markt der zu fast 80% auf Nvidia setzt wenn jetzt eine Schnittstelle kommt, die den Marktführer unter anderem benachteiligt? Wenig.

[Bucklew]

Wieso denn "oder"?
Bei der CPU wird einiges frei.
Ressourcen sind nicht unendlich vorhanden. Ein stärkerer Focus auf LL bedingt immer einen geringeren Focus auf HL.

Weil das in der Natur der Dinge liegt. Es gibt kein perfektes System.
Und zumindest ich beziehe mich nicht nur auf GPUs.
Auch LL ist nicht perfekt. Warum sollte es also ein Muss sein?

Weil es neu und nicht einfach ist.
Eben.

Und damit merkt man: Es ist mitnichten so, dass LL einfach so Potential bietet. Es muss hart und mühsam erkämpft werden auf Dev Seite.

Hä?
Profitierst auch nicht von doppelten FP16 Einheiten, neuen Gameworks Effekten, CPUs mit mehr Kernen usw., weil das jetzt noch nicht genutzt wird.
Nennt sich Fortschritt.
Ich profitiere z.B. nicht von einem 8-Kern statt meinem heutigen 4-Kern Prozessor, wenn der bei identischer IPC nur halb so hoch taktet.

Einige moderne Spielen treiben heutige CPUs an ihre Grenze. Die IPC-Steigerung pro Generation wird immer geringer. Einige Entwickler meinten in Interviews, dass mit LL APIs deutlich besseres Multithreading möglich sein wird.

Sehe nicht warum das nicht gut sein soll.
Wo soll ich geschrieben haben, dass das schlecht ist? :confused:

Meine Kritik richtet sich dahin, dass LL mitnichten der heilige Gral ist, der automatisch Potential freischaltet, dass man heute nicht nutzen kann.

Du solltest vielleicht auch mal zwischen den Zeilen hier lesen wenn sich ein Entwickler dazu äußert. Jetzt nicht speziell auf BF1 bezogen. Schlechte Dokumentation der NV-Hardware wurde öfter erwähnt.
Ach so, die ganzen gammeligen DX12-Ports auf AMD gibt es also deswegen, weil NVIDIA so schlechte Doku liefert ;D

Deinen "balanced PC" gibt es eben nur weil es noch so viele high level Spiele in der PC-Umgebung gibt. Ursache --> Wirkung und so.
Eben. Henne-Ei Problem.

Und solange wie es viele HL-Spiele gibt, macht es sehr viel Sinn, da Ressourcen rein zu stecken. Eine handvoll Spiele vs. fast alle Spiele. Das ist nicht von der Hand zu weisen.

[Hübie]

Was dargo meinte: DX12 läuft auf NV meist schlechter, weil die Devs nicht alle Informationen erhalten die sie benötigen. Das ist bisher jedoch eher Spekulation. Ich weiß zwar, dass für OCL und viele Funktionen der GPUs nur lückenhafte Dokus existieren, aber ob man es generell so sagen kann müssten einige Entwickler hier mal Preis geben. ;) Man erhält gegen Auflage auch mehr Architekturdetails, wenn es als erforderlich erachtet wird.

CUDA abstrahiert ja auch vieles ohne die Abläufe durchblicken zu lassen, aber muss man sich auch fragen ob ein Dev so etwas wissen muss. Er muss eigentlich nur wissen wie er es richtig anwendet, nicht wie es funktioniert.

[pixeljetstream]

imo hatte captain_drink vorher schon sehr gut die Lage zusammengefasst. Ähnlich wie er sehe ich das sich hier viel im Kreis dreht.

Die Grundproblematik besteht darin, dass die Leute oft aneinander vorbei reden, ironischer Weise wissen sie das auch, zeigen es ja der Gegenseite auf, dennoch macht man munter weiter ;) Das andere unschöne ist, dass man wenig Zugeständnisse macht, oft wird alles angriffslustig mit Seitenhieben formuliert.

Zum jetzige Thema in der HL vs LL Diskussion:
Es klingt für mich als würde die HL Fraktion eher wirtschaftlich im PC Jetzt argumentieren, während einige LL Leute eher die technischen Vorzüge für Entwickler hervorheben. Unabhängig davon sollte jedem einleuchten, dass keine Lösung perfekt ist, alles ist ein Kompromiss, alles hat Historie. Es ist immer notwendig die Apis von Zeit zu Zeit den realen Gegebenheiten anzupassen und alles brauch Zeit (Dx11 oder OpenGL waren auch mal relativ "low-level").

Gehen wir von einem fertigen Softwareprodukt aus, so gibt es hier mehrere Schichten (grob):

Game - Engine - Renderabstraktion - Api - Treiber/Betriebssystem - Hardwarelayer (plural!)

Was man nun als HL/LL interpretiert, ist wo die Arbeit in erster Linie passiert/für welche Seite es leichter/billiger usw. ist.
Jede Lösung hat immer HL oder LL Konzepte (weswegen ein grundsätzlicher Glaubenskrieg hier unangebracht ist).

Ich will hier auch betonen, dass es nicht "einen" Übergang von Treiber zu Hardware gibt, sondern die Hardware selber ja auch Abstraktionen beherbergt die es dem Treiber/Entwickler erleichtern.
Mein Eindruck ist, dass das vielen vielleicht nicht so bewusst ist. Oder anders formuliert was für den einen LL Api ist, ist für den anderen vielleicht HL Api, weil die Treiber/Hardwarelayer usw. das ganze dann runterbrechen.
Dies bezieht sich nicht "generell", sondern auf Teillösungen.
Konkrete Beispiele (bitte nicht als "wertend" sehen): Sowohl DX/Vk haben ein System wo der Entwickler Ressourcen in verschiedene Zustände überführen muss. Für einen Hersteller mag das LL sein, weil der Treiber hier wirklich Instruktionen für die Hardware generieren muss, der andere kann eine Architektur haben die das gar nicht brauch.
Ein Hersteller hat verschiedene Memorytypen Caches usw. und der Entwickler muss mit diesen Haushalten, der andere löst das in Hardware anders.

Man könnte nun sagen dass immer die Teillösung besser ist, die es für den Layer davor erleichtert. Allerdings wenn der Layer davor auch unter der eigenen Kontrolle ist, kann man ja selbst ein Balancing machen wo man nun investiert. Die Fläche auf dem Chip muss teurer erkauft werden, als die Software.
(Bei CPUs haben wir eher ein Modell wo lange in viel Intelligenz der Hardware investiert wurde, der "x86" assembly wird dort auch so nicht ausgeführt, der ist quasi auch highlevel code ;) Aber dieser Komfort kostet halt Fläche, Gesamtleistung, aber macht die Platform leicht zugänglich.)

Das ganze geht natürlich nur bis zu einem gewissen Grad und ist eben sehr "individuell", der ganze Layer ist niemals "nur HL/LL". Die Chips werden inkrementell verändert. Und jede "Standard API" ist ein feilschen der Hersteller die Abstraktion so hinzubiegen, dass man möglichst wenig Abstraktion dazwischen hat.

Man sieht gerade auch schön wie AMD/NV jeweils die Stärken des anderen anerkennen, der eine verbessert async compute, der andere verbessert die Geometriepipeline. Das geht nicht von heute auf morgen. Aber das Ergebnis ist doch gut, beide bauen bessere Hardware. Weil beide unterschiedliche Architekturen haben kommen sie auf unterschiedliche Lösungen, die vielleicht nicht immer für den anderen Sinn machen. Man sollte aber dennoch die Arbeit respektieren. Zu sagen die Gegenseite ist Scheiße, macht die Leistung der eigenen doch nicht besser... Für mich klingt dieses Abwerten dann immer so als hätten die fanboys im Prinzip kein Respekt/Verständnis vor der Arbeit an sich. Das heißt nicht das jeder Weg/jede Lösung super ist, alles sind Kompromisse, und es werden definitiv Fehler gemacht, in allen Schichten. Mehr Ressourcen zu haben, erleichtert die Entwicklung, aber ist auch kein Selbstläufer, wo investiert wird, was wichtig ist, ist eine strategische Entscheidung.



Wenn es mir nun um das Endergebnis geht (das Spiel/Software), ist im Prinzip egal wie die Verteilung in den Systemen ist, und im Prinzip auch egal wer welche Verantwortung hatte.

Jeder muss dann individuell entscheiden welcher Kosten/Nutzenfaktor ihm lieber ist. Einmal investiert die Firma in mehrere dieser Schichten selbst, die andere Seite setzt eher auf die Entwickler selbst und hofft dort durch die Hardwareabstraktion zu punkten.
Beides macht je nach Betrachtung Sinn, und beides ist nicht ohne Problem. Das sollte man anerkennen, wirtschaftlich gesehen richtet der Markt über die Strategien...

[VooDoo7mx]

Ich weiß nicht was das soll, aber es gibt auch haufenweise Spiele mit DX12 und Vulkan Pfaden die mit AMD nicht besser oder genau wie bei nVidia sogar schlechter laufen. Die einzigen Spiele wo AMD Karten profitieren sind immer die selben paar und dafür hat wird AMD auch ordentlich gezahlt haben. Nicht umsonst macht ja Tiago Sousa auf seinen Twitter Account Werbung für AMD Karten.
Ich frag mich echt immer wie man das als Allheilmittel für alles verstehen kann. Der Aufwand für Programmierer steigt enorm. Man kann ja nicht nur einen allgemeinen Pfad machen, sondern muss für jede Chipgeneration oder am besten für jeden einzelnen Chip entsprechende Anpassungen einbauen. Deswegen stinken auch in einigen Spielen nVidia Karten ab und sind sogar schlechter, einfach weil der von AMD bezahlte DX12/Vulkan Pfad nur AMD Karten berücksichtigt.
Es ist im Endeffekt sehr vergleichbar mit dem VXAO Gameworks Effekt. Der nutzt auch Hardwarefeatures von Maxwell/Pascal und das stinkt dann auf anderer Hardware eben ab. Nichts anderes sind im Endeffekt die von AMD bezahlten DX12/Vulkan Pfade.
Aber die Fanatischen Fanboys die Grafikkarten als Ersatzrelegion benötigen, sehen dies immer natürlich nur in einer Richtung.

[dargo]

Was dargo meinte: DX12 läuft auf NV meist schlechter, weil die Devs nicht alle Informationen erhalten die sie benötigen. Das ist bisher jedoch eher Spekulation. Ich weiß zwar, dass für OCL und viele Funktionen der GPUs nur lückenhafte Dokus existieren, aber ob man es generell so sagen kann müssten einige Entwickler hier mal Preis geben. ;)
Es gab hier schon paar Infos dazu. Ihr solltet mal die wichtigen Informationen aufnehmen und vielleicht weniger auf die Trolle, die immer wieder dazwischen stören eingehen.

[Grendizer]

Nachdem ja Forza 7 nur DX11 unterstützen wird, noch ein potentieller DX12 Titel weniger. Irgendwie haben die Entwickler nicht wirklich Bock drauf.
Quelle: https://www.3dcenter.org/news/die-systemanforderungen-zu-forza-motorsport-7

[Bucklew]

Nachdem ja Forza 7 nur DX11 unterstützen wird, noch ein potentieller DX12 Titel weniger. Irgendwie haben die Entwickler nicht wirklich Bock drauf.
Ja, aus genannten Gründen.

Es würde mich nicht wundern, wenn viele aktuellen Neuentwicklungen im frühen Entwicklungsstadium sowohl DX11, als auch DX12 implementieren und dann feststellen, dass sie mir DX11 einfach besser fahren.

Es gab hier schon paar Infos dazu. Ihr solltet mal die wichtigen Informationen aufnehmen und vielleicht weniger auf die Trolle, die immer wieder dazwischen stören eingehen.
Ach komm, so viele gehen nun wirklich nicht auf deine Postings ein.... :freak:

[dargo]

Nachdem ja Forza 7 nur DX11 unterstützen wird, noch ein potentieller DX12 Titel weniger. Irgendwie haben die Entwickler nicht wirklich Bock drauf.
Quelle: https://www.3dcenter.org/news/die-systemanforderungen-zu-forza-motorsport-7
Wo hat Leonidas diese Info her? In seinen Links steht nichts von DX11, wäre auch total bescheuert von Microsoft.

[Hübie]

Man sieht gerade auch schön wie AMD/NV jeweils die Stärken des anderen anerkennen, der eine verbessert async compute, der andere verbessert die Geometriepipeline. Das geht nicht von heute auf morgen. Aber das Ergebnis ist doch gut, beide bauen bessere Hardware. Weil beide unterschiedliche Architekturen haben kommen sie auf unterschiedliche Lösungen, die vielleicht nicht immer für den anderen Sinn machen. Man sollte aber dennoch die Arbeit respektieren. Zu sagen die Gegenseite ist Scheiße, macht die Leistung der eigenen doch nicht besser... Für mich klingt dieses Abwerten dann immer so als hätten die fanboys im Prinzip kein Respekt/Verständnis vor der Arbeit an sich. Das heißt nicht das jeder Weg/jede Lösung super ist, alles sind Kompromisse, und es werden definitiv Fehler gemacht, in allen Schichten. Mehr Ressourcen zu haben, erleichtert die Entwicklung, aber ist auch kein Selbstläufer, wo investiert wird, was wichtig ist, ist eine strategische Entscheidung.

Das stimmt. Sollten wir wirklich mehr beherzigen, denn wenn ich mich so umsehe, könnten fast alle hier Anwesenden wohl nicht mal die vier Grundrechenarten in Hardware implementieren, geschweige denn per Software noch zusätzlich ansprechen. :biggrin:

Als Verbraucher interessiert uns aber nicht, das Wer, Wie oder Warum, sondern nur das Was (das hinten raus kommt :D).
Ich stelle auch gerade fest, dass AMDs Initiative, den Entwicklern Effektbibliotheken zur Verfügung zu stellen (GPUOpen: ShadowFX, GeometryFX,ShadowFX etc.), keine Beachtung geschenkt wird. Trotz der freien Lizenz. Warum, wieso, weshalb? Ist da was angekündigt oder passiert das so latent, dass es keiner mitbekommt? :|

Edit: @dargo: Ich glaube da hat Leo sich geirrt. ;)

[Grendizer]

Ja scheint wirklich ein Fehler zu sein:

http://wccftech.com/forza-motorsport-7-pc-system-requirements-revealed/

DirectX: DirectX 12 API, Hardware Feature Level 11

[StefanV]

Insbesondere nachdem die XBox wohl DX12 bekommen haben soll, macht es kaum Sinn, das nicht zu nutzen...

[HOT]

Forza7 hat das gleiche DX und Featurelevel wie Forza 3 Horizon. Alles andere ist pure Fehlinformation. Es ist halt die gleiche Technik.

Meine Güte, ist das grausam, wieviele NV-Trolle sich wieder hier tummeln...

DX11 ist das Maß aller Dinge, DX12 ist scheisse und setzt sich eh nicht durch... so ein BS, unglaublich. DX12 setzt sich natürlich durch, die Frage stellt sich gar nicht, die Überwindung des Drawcalllimits und die direktere Kontrolle der Hardware ist für Entwickler, grade bei AAA-Titeln, einfach essenziell. Natürlich dauert der Umstieg seine Zeit, aber wenn man Zeit ins Land gehen lässt wird Win7 eh irrelevant und sowieso nur noch DX12, und in einigen Fällen Vulkan, verwendet. Das war bei allen bisherigen DX-Versionen genauso, der Umstieg braucht halt seine Zeit, aber er ist schlicht nicht aufzuhalten, auch nicht von NV-Gläubigen. NV selber weiss das genau und tut alles dafür, DX12 so gut wie möglich zu unterstützen. Leider sind die ganzen Fanboys einfach nur blind vor Arroganz...

[StefanV]

DX12 setzt sich natürlich durch,
...allein schon aufgrund der Nähe zur XBox One wird sich das durchsetzen. Wer was anderes behauptet, träumt einfach.
Dauert natürlich, wie alles, immer etwas. Braucht halt Vorlaufzeit...

[Bucklew]

DX11 ist das Maß aller Dinge, DX12 ist scheisse und setzt sich eh nicht durch... so ein BS, unglaublich.
Stimmt, unglaublicher Bullshit, den du da erzählst. Weil nichts von dem hat irgendwer hier geschrieben - zumindest nicht auf den letzten 5-10 Seiten. :freak:

:facepalm:

[Grendizer]

... Das war bei allen bisherigen DX-Versionen genauso, der Umstieg braucht halt seine Zeit, aber er ist schlicht nicht aufzuhalten, auch nicht von NV-Gläubigen. NV selber weiss das genau und tut alles dafür, DX12 so gut wie möglich zu unterstützen. Leider sind die ganzen Fanboys einfach nur blind vor Arroganz...

Bei allen bisherigen DX Versionen war mit dem Umstieg aber auch neue visuelle Effekte möglich. Bei DX 12 ist der Fokus aber ein anderer. Und bisher geht der Umstieg Richtung DX12 nach anfänglichen medienwirksamen Start mit einigen hochkarätigen Titeln doch sehr langsam von statten.

[HOT]

Stimmt, unglaublicher Bullshit, den du da erzählst. Weil nichts von dem hat irgendwer hier geschrieben - zumindest nicht auf den letzten 5-10 Seiten. :freak:

:facepalm:
Träum weiter. Das ist ständig der Subtext. Andauernd.

Grendizer
Visuelle Effekte á la DX7 und 8 gibt es seit 15 Jahren nicht mehr... seit DX9 erweitert sich einfach die Programmierbarkeit, was natürlich indirekt bessere Effekte ermöglicht. DX12 ist da nicht anders. Das ist also blödsinnig das Argument. DX12 ist der nächste Evolutionsschritt und da wird es auch nicht enden.

In 2018/19 werden die ganzen großen Engines die DX12 und Vulkan-Renderer zum Defaultrenderer machen, mit 1-x Jahren Verzögerung kommen damit die ersten Spiele... Win7 läuft bis dahin eh langsam aus, das ist alles glasklar wie das laufen wird.

[Grendizer]

Träum weiter. Das ist ständig der Subtext. Andauernd.

Grendizer
Visuelle Effekte á la DX7 und 8 gibt es seit 15 Jahren nicht mehr... seit DX9 erweitert sich einfach die Programmierbarkeit, was natürlich indirekt bessere Effekte ermöglicht. DX12 ist da nicht anders. Das ist also blödsinnig das Argument. DX12 ist der nächste Evolutionsschritt und da wird es auch nicht enden.

In 2018/19 werden die ganzen großen Engines die DX12 und Vulkan-Renderer zum Defaultrenderer machen, mit 1-x Jahren Verzögerung kommen damit die ersten Spiele... Win7 läuft bis dahin eh aus, das ist alles glasklar wie das laufen wird.

Bis dahin interessiere ich mich doch nicht mehr was dann jetzt aktuelle Karten können. Damit ist die ganze Diskussion doch fürn Arsch. Bis 2019 habe ich doch schon wieder 1-2 neue Karten gekauft.

[HOT]

Bis dahin interessiere ich mich doch nicht mehr was dann jetzt aktuelle Karten können. Damit ist die ganze Diskussion doch fürn Arsch. Bis 2019 habe ich doch schon wieder 1-2 neue Karten gekauft.
So ist das eben. Damit lebt NV ja auch sehr gut. AMD ist technisch immer der Motor und NV partizipiert, das ist seit GCN1 so.
Aber dennoch geschieht die Evolution eigentlich in hoher Geschwindigkeit.

2013 -> DX12 am Reißbrett
2014 -> Vulkan am Reißbrett
2015 -> erste DX12-Iteration, sehr fehlerhaft
2016 -> erste DX12-Titel, erste Vulkan-Iteration, ziemlich experimentell (Pascal/Polaris)
2017 -> erste Flaute, alles bisher waren Einzelintegrationen - das geht natürlich zurück, DX12/Vulkan wandern flächig in die großen Engines (Vega)
2018 -> erste Titel mit DX12/Vulkan auf Enginerendererbasis erscheinen (Gaming Volta + Navi)
2019 -> DX12/Vulkan werden Defaultrenderer bei den großen Engines, je nach Anwendungszweck der Engine und je nach Konsolenbasis (NVs 7nm-Generation)
2020 -> erste Spiele mit reinem DX12-Support erscheinen (abseits von UWP natürlich) (AMDs 7nm EUV-Generation)

Software braucht nunmal Zeit. Und ohne GCN und ohne Dice's Engagement wär das alles nicht so schnell möglich gewesen, das wollen wir ja mal ganz klar sagen.

[Grendizer]

So ist das eben. Damit lebt NV ja auch sehr gut. AMD ist technisch immer der Motor und NV partizipiert, das ist seit GCN1 so.
Aber dennoch geschieht die Evolution eigentlich in hoher Geschwindigkeit.

Software braucht nunmal Zeit. Und ohne GCN und ohne Dice's Engagement wär das alles nicht so schnell möglich gewesen, das wollen wir ja mal ganz klar sagen.


Mich erinnert DX12 so ein wenig an Transform und Lightning auf der Geforce 2 damals. Da wurden die Massen auch irre gemacht, das man das Superfeature unbedingt braucht. Auch ich habe mir damals eine Elsa Gladiac 2 GTS gekauft (ich glaube damals 799 DM). Als die ersten Spiele damit rauskamen, hatte ich schon wieder was ganz anderes im Rechner.

[HOT]

Mich erinnert DX12 so ein wenig an Transform und Lightning auf der Geforce 2 damals. Da wurden die massen auch irre gemacht, das man das Superfeature unbedingt braucht. Auch ich habe mir damals eine Elsa Gladiac 2 GTS gekauft (ich glaube damals 799 DM). Als die ersten Spiele damit rauskamen, hatte ich schon wieder was ganz anderes im Rechner.
Na dann spiel mal DX7 Titel ohne T&L... ich bin gespannt. Um's vorweg zu nehmen, es gab PCGH-Artikel letztes Jahr, die das beleuchtet haben - du sitzt da einem Mythos auf. Ohne T&L waren etliche Titel arschlangsam. Voodoo und Kyro hatten unter DX7 bei einigen Titeln nie ne wirkliche Chance, weil sich die Spielehersteller auf Geforce+Radeon konzentriert haben. Auch S3 ging den Bach runter, weil T&L nicht lief - nur das hätte den Savage2000 retten können.

[Bucklew]

Träum weiter. Das ist ständig der Subtext. Andauernd.
;D

Der Subtext bei dir, dass die kleineren Pascal-Ableger erst 2017 erscheinen sollen ;D

2013 -> DX12 am Reißbrett
2014 -> Vulkan am Reißbrett
Laut NVIDIA begannen die ersten Gespräch über DX12 im Jahre 2010.

[Gimmick]

Gab mit Q3 auch direkt einen Titel, der davon profitiert hat.
Wurde auch direkt die NV15DEMO Map rausgebracht, die das eindrucksvoll demonstriert hat ^^.

[dargo]

Laut NVIDIA begannen die ersten Gespräch über DX12 im Jahre 2010.
Also zwei Jahre später nachdem Johan Andersson sich an die Grafikkartenhersteller gewandt hatte.

Mmmmmh..... lecker Kirschen! Du hast du aber schön gepflückt! ;D

Ich kann noch mehr pflücken, verträgst du es auch? Vega56 Referenz vs. MSI GTX1080 Gaming.

https://www2.pic-upload.de/img/33804000/Dirt4.jpg

https://www2.pic-upload.de/img/33804001/Warhammer.jpg

https://www2.pic-upload.de/img/33804002/Quake.jpg

Beim letzteren bin ich mir jetzt nicht sicher ob das OpenGL oder schon Vulkan ist. Vulkan wollte man eigentlich später nachreichen. Zumindest war das Stand vor wenigen Monaten.

Quelle (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11471514&postcount=1589)

Edit:
Quake Champions läuft aktuell mit DX11.
http://www.pcgameshardware.de/Quake-Champions-Spiel-57337/Specials/Beta-Benchmark-Test-Review-Engine-1226705/

[Loeschzwerg]

Warum muss man Screenshots von einem YT Video posten, wenn es alles auch in geschriebener Form gibt :freak:
https://www.techspot.com/review/1476-amd-radeon-vega-64/

[N0Thing]

@pixeljetstream

Danke für deinen Beitrag. Das war sowohl angenehm als auch interessant zu lesen. Wäre schön, wenn sich alle eine Scheibe davon abschneiden. Manchmal denkt man bei der "Diskussion", man sei an einem Fußballstammtisch. Das Spiel mögen alle, nur wenn es von Verein XY kommt, ist alles scheiße.


Na dann spiel mal DX7 Titel ohne T&L... ich bin gespannt. Um's vorweg zu nehmen, es gab PCGH-Artikel letztes Jahr, die das beleuchtet haben - du sitzt da einem Mythos auf. Ohne T&L waren etliche Titel arschlangsam. Voodoo und Kyro hatten unter DX7 bei einigen Titeln nie ne wirkliche Chance, weil sich die Spielehersteller auf Geforce+Radeon konzentriert haben.

Der Kyro II hatte vor allem keine Chance, weil viele Titel Hardware T&L vorausgesetzt haben, obwohl das nicht notwendig gewesen wäre. Schade, daß der Kyro III nie das Licht der Welt erblickt hat. :(

[Kriton]

Wer bist du denn? ;D

Ich darf doch wohl selbst wählen, welches Argumente ich hier vorbringe oder nicht. Und wenn der Vergleich mit AMD eben belegt, dass das Potential bei NVIDIA gar nicht so groß sein kann, wie bei AMD, warum sollte ich das dann nicht vorbringen? Nur weil du es nicht widerlegen kannst und bisher 0 (in Worten: null) Belege für deine Behauptung gebracht hast? ;D

Ein letzter Versuch. Das war meine ursprüngliche Aussage:

Ihr (Du und Bucklew) habt einen Denkfehler. Euer Bezugspunkt (Leistung AMD) ist falsch. Die Frage ist, wie performant könnte (nicht ist) Nvidia unter einer LL-API im Vergleich zu DX 11 sein? Es wäre sehr verwunderlich, wenn da keine Mehrleistung generiert werden könnte. Aber das bedarf naturgemäß einer ordentlichen Doku.
Nur wenn entweder die Entwickler (zufällig) perfekt auf die Nvidia-Architektur optimiert hätten (was üblicherweise nicht der Fall ist, wie wir auch an den speziellen Spieletreibern sehen) und/oder Nvidia sämtliche nicht optimalen Codebestandteile austauschen könnte/würde (was utopisch sein dürfte) hätten wir wohl kein Steigerungspotential.
Ich bezweifele, dass jemand der hier schon mal wirklich hardwarenah programmiert hat das bestreiten würde.

Was ihr also momentan beschreibt (und falsch zuordnet) ist nicht das mangelnde Potential von Nvidia bei LL, sondern die im Vergleich zu AMD höhere Optimierung bei DX 11.

Meine Aussage dreht sich also nicht um einen Vergleich von AMD und Nvidia, sondern allein um die Frage welche Potential (in Bezug auf Leistungssteigerung) Nvidia auf DX12 oder Vulkan im Vergleich zu DX 11 hat. Daher ist Deine Aussage mit AMD auch kein Gegenargument zu meiner Aussage - darauf wollte ich hinaus. Ansonsten sind wir bei etwas wie:

1. Aussage: "Die Rose ist rot."
2. Aussage: "Nelken riechen aber besser."

Da ist kein Widerspruch.

Vielleicht wird es verständlicher wenn ich 2 Aussagen treffe:

1. Nvidia ist für DX11 besser optimiert als AMD.
2. Unabhängig davon wird sich die Leistung von Nvidia ebenfalls noch (in unbekannter Höhe) steigern lassen, wenn die Entwickler die vollen Möglichkeiten von DX 12 oder Vulkan nutzen.

Können wir uns auf diese beiden Aussagen einigen?


Du solltest dich mal grundsätzlich mit der Codeentwicklung, Assemblern, Compilern und speziell Codeoptimierung beschäftigen.

Nur weil man mit Assemblern den (theoretisch) am besten optimierten und daher schnellsten Code programmieren kann, heißt dies noch lange nicht, dass das auch 100% aller Programmier schaffen.

Und hier ist der Krucks. Die Erfahrung, Man-Power und Schluss endlich Zeit und Geld, die investiert werden muss, damit LL Code (egal ob auf CPU oder GPU) besser ist, als das, was automatisiert erzeugt wird (egal ob durch einen Compiler oder durch einen GPU-Treiber), steht fast immer in keinem Verhältnis zur erreichten Mehrperformance.

Oder erkläre mir doch mal, wenn doch LL der heilige Gral ist und da ja ach so viel Performance brach liegt bei NVIDIA - warum schafft es dann nicht mal DICE (sicherlich eine der Top-Adressen weltweit, was Grafikengine-Entwicklung angeht) einen performanten DX12-Port hinzukriegen in BF1?

Hier reden wir offenbar wieder aneinander vorbei (@pixeljetstream, ich höre Dich): Mein Argument war prinzipiell. Also, dass es (von mir aus theoretisch) möglich ist. Davon, dass es 100% der Programmierer können habe ich nicht geredet - in diesem Kontext wäre es gut, wenn wir uns auf die jeweiligen Aussagen des anderen in der Argumentation reduzieren könnten. Gegenarguemten zu Aussagen, die nicht getroffen wurden bringen uns inhaltlich nicht weiter.
Du argumentierst mit einer Kosten-Nutzen-Rechnung. Beides schließt sich nicht aus (s.o.). Deinem Argument würde ich weder zustimmen noch entgegentreten, da mir die technischen Kenntnisse im Hinblick auf die HW von Nvidia und die relevanten APIs fehlen. Aber aus meiner Sicht widersprechen wir uns hier nicht.
Aber auch hier läuft es (IMHO) letztlich auf meine beiden o.g. Aussagen hinaus.

[Bucklew]

Ich kann noch mehr pflücken, verträgst du es auch? Vega56 Referenz vs. MSI GTX1080 Gaming.
Logo. Jede Ausnahme belegt eben die Regel, die ich aufgestellt habe ;)

Wer wie du versucht den Vorsprung von NVIDIA in Sachen DX11 mit ein, zwei Benchmarks wegzuwischen, dem ist eben einfach nicht mehr zu helfen ;D

Meine Aussage dreht sich also nicht um einen Vergleich von AMD und Nvidia, sondern allein um die Frage welche Potential (in Bezug auf Leistungssteigerung) Nvidia auf DX12 oder Vulkan im Vergleich zu DX 11 hat.
Und meine Antwort darauf ist ganz klar: Alleine aufgrund der technischen Daten und der aktuellen Benchmarks wissen wir, dass das Potential von NVIDIA geringer sein muss, als bei AMD.

Dabei ist immer noch die Frage ungeklärt, ob es überhaupt ein Potential größer Null gibt.

Daher ist Deine Aussage mit AMD auch kein Gegenargument zu meiner Aussage - darauf wollte ich hinaus.
Du hast keine Aussage, sondern nur eine Behauptung. Für eine Aussage, müsstest du das Potential belegen können.

2. Unabhängig davon wird sich die Leistung von Nvidia ebenfalls noch (in unbekannter Höhe) steigern lassen, wenn die Entwickler die vollen Möglichkeiten von DX 12 oder Vulkan nutzen.

Können wir uns auf diese beiden Aussagen einigen?
Nein. Weil die Aussage allgemein gültig einfach falsch ist. Viele gammlige DX12-Ports belegen das eindeutig. Egal ob unter AMD oder NVIDIA.

LL ist eben nicht der heilige Gral, mit dem auf magischem Wege die Spiele plötzlich 100% schneller laufen, im Gegenteil.

Mein Argument war prinzipiell. Also, dass es (von mir aus theoretisch) möglich ist. Davon, dass es 100% der Programmierer können habe ich nicht geredet - in diesem Kontext wäre es gut, wenn wir uns auf die jeweiligen Aussagen des anderen in der Argumentation reduzieren könnten. Gegenarguemten zu Aussagen, die nicht getroffen wurden bringen uns inhaltlich nicht weiter.
Die Frage ist, worüber wir diskutieren. Das LilaWunderLand, in dem Entwickler zu 100% perfekte Programmierer sind, unendlich viel Zeit und Geld haben oder leben wir in der Realität und es geht darum was unterm Strich praktisch dem Kunden am Meisten bringt?

Du bist beim ersten Szenario, ich beim Zweiten.

Du argumentierst mit einer Kosten-Nutzen-Rechnung. Beides schließt sich nicht aus (s.o.). Deinem Argument würde ich weder zustimmen noch entgegentreten, da mir die technischen Kenntnisse im Hinblick auf die HW von Nvidia und die relevanten APIs fehlen. Aber aus meiner Sicht widersprechen wir uns hier nicht.
Und genau dies stört mich an dieser Diskussion: Du behauptest etwas, ohne Ahnung zu haben, und beharrst dann auf dieser Behauptung, auch wenn dir jemand valide Indizien und Belege liefert, dass die Behauptung nicht allgemein gültig sein kann. Das ist einfach sinnlos und keine Diskussion.

[Kriton]

Logo. Jede Ausnahme belegt eben die Regel, die ich aufgestellt habe ;)

Wer wie du versucht den Vorsprung von NVIDIA in Sachen DX11 mit ein, zwei Benchmarks wegzuwischen, dem ist eben einfach nicht mehr zu helfen ;D


Und meine Antwort darauf ist ganz klar: Alleine aufgrund der technischen Daten und der aktuellen Benchmarks wissen wir, dass das Potential von NVIDIA geringer sein muss, als bei AMD.

Dabei ist immer noch die Frage ungeklärt, ob es überhaupt ein Potential größer Null gibt.


Du hast keine Aussage, sondern nur eine Behauptung. Für eine Aussage, müsstest du das Potential belegen können.


Nein. Weil die Aussage allgemein gültig einfach falsch ist. Viele gammlige DX12-Ports belegen das eindeutig. Egal ob unter AMD oder NVIDIA.

LL ist eben nicht der heilige Gral, mit dem auf magischem Wege die Spiele plötzlich 100% schneller laufen, im Gegenteil.


Die Frage ist, worüber wir diskutieren. Das LilaWunderLand, in dem Entwickler zu 100% perfekte Programmierer sind, unendlich viel Zeit und Geld haben oder leben wir in der Realität und es geht darum was unterm Strich praktisch dem Kunden am Meisten bringt?

Du bist beim ersten Szenario, ich beim Zweiten.


Und genau dies stört mich an dieser Diskussion: Du behauptest etwas, ohne Ahnung zu haben, und beharrst dann auf dieser Behauptung, auch wenn dir jemand valide Indizien und Belege liefert, dass die Behauptung nicht allgemein gültig sein kann. Das ist einfach sinnlos und keine Diskussion.

Argumenta ad hominem? Von Dir? Hattest Du Dich nicht dagegen ausgesprochen?
Zu Deinen "Gegenbeweisen": Ich vermute, Du beziehst dich (der Quote ist nur beispielhaft) auf:

Viele gammlige DX12-Ports belegen das eindeutig

Was belegen sie? Das DX 12 nicht automatisch schneller ist als DX 11? Stimmen wir überein. Das sagt aber nichts über das Potential von DX 12.

Es würde aber auch schon helfen, wenn Du meine Aussagen nicht änderst um sie dann als lächerlich zu brandmarken. Wenn ich sage, dass eine Leistungssteigerung möglich ist und ich explizit keine Aussage zu deren Höhe mache, dann kommst Du mit 100% und LilaWunderLand - so können Diskussionen nicht funktionieren.

Meine Aussage ist übrigens argumentativ belegt:


Ansonsten kannst Du versuchen mir zu erklären wie Du darauf kommst, dass die Umsetzung einer Prozedur auf einem gegebenen System in einer Hochsprache prinzipiell nicht effizienter in Assembler (mir ist klar, dass wir hier im konkreten Fall nicht über Assembler reden - es geht nur um das Prinzip) programmiert werden kann.
Das würde IMHO voraussetzen, dass der Compiler (bezogen auf das System auf dem der Code laufen soll) in jedem Anwendungsfall grundsätzlich perfekten Code erzeugt. Das ist... unwahrscheinlich.

Wenn Dein (einziges) Gegenargument letztlich eine Kosten-Nutzen-Rechnung ist, dann können wir hier aufhören. Denn dagegen argumentiere ich gar nicht (wie ich mehrfach ausgeführt habe) - dazu kann ich schlicht nichts sagen.

[Bucklew]

Argumenta ad hominem? Von Dir? Hattest Du Dich nicht dagegen ausgesprochen?
Du hast doch selbst eingestanden, keine Kenntnisse zu haben. Nun bist du beleidigt, wenn ich darauf eingehe? ;D

Was belegen sie? Das DX 12 nicht automatisch schneller ist als DX 11? Stimmen wir überein. Das sagt aber nichts über das Potential von DX 12.
Doch. Keine Steigerung in DX12 = Kein Potential.

Bitte liefere einen Beweis dafür, dass 100% aller Grafikengines in DX12 schneller wären, als in DX11. Das behauptest du nämlich. Ohne einen Beleg oder Beweis dafür.

Wie auch? Es ist gar nicht möglich, diesen Beweis zu führen!

Es würde aber auch schon helfen, wenn Du meine Aussagen nicht änderst um sie dann als lächerlich zu brandmarken. Wenn ich sage, dass eine Leistungssteigerung möglich ist und ich explizit keine Aussage zu deren Höhe mache, dann kommst Du mit 100% und LilaWunderLand - so können Diskussionen nicht funktionieren.
Nochmal: Zu sagen eine Leistungssteigerung ist möglich - das kannst du einfach nicht allgemein gültig sagen. Punkt.

Es wird auch niemals der Fall sein. Es wird einfach Grafikengines geben, die mit DX12 nicht gut harmonieren. Ob dir das passt oder nicht.

Meine Aussage ist übrigens argumentativ belegt:
Das hatte ich dir bereits widerlegt, leider kannst du das ja mangels Kenntnisse nicht nachvollziehen. Aber so ist die Diskussion dann sinnlos.

Wenn Dein (einziges) Gegenargument letztlich eine Kosten-Nutzen-Rechnung ist, dann können wir hier aufhören. Denn dagegen argumentiere ich gar nicht (wie ich mehrfach ausgeführt habe) - dazu kann ich schlicht nichts sagen.
Nein, Kosten/Nutzen-Rechnung ist nur ein Teil meiner Argumentation.

[IchoTolot]

Wie soll denn DX12 schneller als DX11 sein, wenn man sich im GPU-Limit bewegt? Der Sinn von LL APIs ist doch nur, den Overhead zu reduzieren und die Hardware direkter und effizienter anzusprechen. Das ist dann aber mehr Aufwand für den Spieleentwickler, eben ein Grund wieso da bisher nichts von zu sehen ist und DX12 fast immer schlechter läuft.

Grade bei DX11 macht der nVidia Treiber eine fantastische Arbeit, weswegen bei nVidia Karten auch selten eine Steigerung bei DX12 zu sehen ist.

[Kriton]

Du hast doch selbst eingestanden, keine Kenntnisse zu haben. Nun bist du beleidigt, wenn ich darauf eingehe? ;D

Ich habe gesagt, dass ich in einem spezifischen Bereich keine Kenntnisse habe und deswegen nichts dazu sage. Das auf meine sonstigen Aussagen auszuweiten ist schlicht falsch. Auch den Plural habe ich nicht umsonst verwendet.


Doch. Keine Steigerung in DX12 = Kein Potential.

Bitte liefere einen Beweis dafür, dass 100% aller Grafikengines in DX12 schneller wären, als in DX11. Das behauptest du nämlich. Ohne einen Beleg oder Beweis dafür.

Wie auch? Es ist gar nicht möglich, diesen Beweis zu führen!

Ok, dann bitte mal einen Quote meiner Aussage wo ich sage, dass "100% aller Grafikengines in DX12 schneller wären, als in DX11".

In meinem letzten Post habe ich es schon gesagt (und vorher teilweise auch schon mal angedeutet): Wir können nicht diskutieren (sofern du das möchtest), wenn Du meine Aussagen verdrehst um dann gegen Dinge zu argumentieren, die ich nie gesagt habe.


Nochmal: Zu sagen eine Leistungssteigerung ist möglich - das kannst du einfach nicht allgemein gültig sagen. Punkt.

Es wird auch niemals der Fall sein. Es wird einfach Grafikengines geben, die mit DX12 nicht gut harmonieren. Ob dir das passt oder nicht.

Natürlich kann es (und wird es vermutlich) Engines geben, die mit DX12 nicht gut harmonieren - das sagt aber nichts über die grundsätzliche Möglichkeit von DX12 (oder Vulkan) im Vergleich zu DX 11 aus.


Das hatte ich dir bereits widerlegt, leider kannst du das ja mangels Kenntnisse nicht nachvollziehen. Aber so ist die Diskussion dann sinnlos.

Möglicherweise ist Dir entgangen, was ich auf Deine "Widerlegung" geantwortet habe. Und Du kannst davon ausgehen, dass ich verstehe wovon ich da geschrieben habe. Sonst hätte ich (wie an anderer Stelle) gesagt, dass ich dazu mangelns Kenntnissen nichts sagen kann.


Nein, Kosten/Nutzen-Rechnung ist nur ein Teil meiner Argumentation.

Was ist der andere Teil? Der Skill der Programmierer?

Noch einmal: Ich behaupte nicht, dass DX12 für jeden Anwendungsfall besser wäre, sondern nur dass bei hinreichenden Kenntnissen und Fähigkeiten seitens der Programmierer eine hardwarenähere Programmierung ein besseres Endergebnis liefert als eine abstraktere (aufgrund der Limitationen eines Compilers). Ob der dafür notwendige Aufwand gerechtfertigt ist und wie hoch die Steigerung ist, ist eine andere Frage, für die gemachte Aussage in ihrem Abstraktionsgrad aber auch nicht entscheidend.

[Gimmick]

Die Frage ist, worüber wir diskutieren. Das LilaWunderLand, in dem Entwickler zu 100% perfekte Programmierer sind, unendlich viel Zeit und Geld haben oder leben wir in der Realität und es geht darum was unterm Strich praktisch dem Kunden am Meisten bringt?

Du bist beim ersten Szenario, ich beim Zweiten.


Jo, das macht DX12 aber ansich nicht schlechter.

Es will ja auch keiner sagen, dass jetzt jeder Indie-Hersteller auf DX12/Vulkan setzen soll.
Aber Spieleschmieden, die großes wollen, müssen die bittere Pille aus meiner Sicht halt schlucken und den Kram gescheit umsetzen. Umfangreiche OpenWorld Titel sind auch mit den dicksten Prozessoren oft CPU limitiert und/oder haben kein gutes Multithreading.

Da bleiben keine Optionen übrig.

[dargo]

Wer wie du versucht den Vorsprung von NVIDIA in Sachen DX11 mit ein, zwei Benchmarks wegzuwischen, dem ist eben einfach nicht mehr zu helfen ;D

Zählen kannst du also auch nicht... respekt.

Wie soll denn DX12 schneller als DX11 sein, wenn man sich im GPU-Limit bewegt?
Das geht ohne Probleme bei GCN auch im GPU-Limit, wenn man eben GCN Features auch nutzt.


Nein. Weil die Aussage allgemein gültig einfach falsch ist. Viele gammlige DX12-Ports belegen das eindeutig. Egal ob unter AMD oder NVIDIA.

Dann zähle mal die gammeligen DX12 Umsetzungen auf die bei GCN schlecht laufen? Mir fällt nur Deus Ex ein welches zwar eine höhere Framerate mit DX12 liefert, im Spiel aber recht schlechte Frametimes. Bei DX11 ist es aber auch nicht wirklich besser was Frametimes angeht. Bei BF1 @GCN und DX12 kenne ich den aktuellen Stand nicht. Frames sind höher, Frametimes Fragezeichen. Keiner meldet sich diesbezüglich zu Wort.

Edit:
Zu BF1 habe ich das hier gefunden. Ist aber nur der Singleplayer und leider auch schon 7 Monate alt.
https://www.youtube.com/watch?v=cCezf-mwKPo&

Das hier ist zwar aktueller, aber ein 4 Threader ist in BF1 einfach am Ende. Da hilft dann auch kein DX12.
https://www.youtube.com/watch?v=2xOS5VcfaIg

[Bucklew]

Es will ja auch keiner sagen, dass jetzt jeder Indie-Hersteller auf DX12/Vulkan setzen soll.
Das ist aber genau mein Argument, dem sich hier heftig widersetzt wird ;)

Aber Spieleschmieden, die großes wollen, müssen die bittere Pille aus meiner Sicht halt schlucken und den Kram gescheit umsetzen. Umfangreiche OpenWorld Titel sind auch mit den dicksten Prozessoren oft CPU limitiert und/oder haben kein gutes Multithreading.
Also wenn eine Spieleschmiede nicht mal ihren CPU-Part als gutes MT hinkriegt, sollen die gleichzeitig ihre Grafik-API fast vollkommen selbst in den Griff kriegen?

Sorry, aber das passt nicht. Auf der einen Seite völlige Dilettanten, aber dann die Götter auf Grafikseite? Glaube ich nicht dran, sorry.

Ok, dann bitte mal einen Quote meiner Aussage wo ich sage, dass "100% aller Grafikengines in DX12 schneller wären, als in DX11".
Hier:
Ich habe gar nichts dazu gesagt, wie groß das Potential ist (das kann ich gar nicht, weil mir dazu das Wissen fehlt), sondern nur argumentiert dass es da ist.
Wie kannst du freimütig behaupten, dass Potential da wäre, wenn du a) weder weißt, ob dem wirklich so ist, b) die Höhe gar nicht spezifizieren kannst noch c) über ausreichende Kenntnisse verfügst das zu bewerten, wie du selbst eingestehst?

In meinem letzten Post habe ich es schon gesagt (und vorher teilweise auch schon mal angedeutet): Wir können nicht diskutieren (sofern du das möchtest), wenn Du meine Aussagen verdrehst um dann gegen Dinge zu argumentieren, die ich nie gesagt habe.
Ich verdrehe hier gar nichts. Du behauptest - ohne Einschränkung - dass DX12 per se gegenüber DX11 Potential hat. Und das ist einfach falsch. Das kannst du nicht einfach behaupten, weil es einfach nicht stimmt. Belege gibt es massig.

Natürlich kann es (und wird es vermutlich) Engines geben, die mit DX12 nicht gut harmonieren - das sagt aber nichts über die grundsätzliche Möglichkeit von DX12 (oder Vulkan) im Vergleich zu DX 11 aus.
Doch, weil hier genau der Punkt ist.

Was ist denn besser für den Kunden? Optimierungen in DX11, die bei 99,9999% der Spiele greifen oder Optimierungen bei DX12, die bei den restlichen 0,0001% greifen?

Möglicherweise ist Dir entgangen, was ich auf Deine "Widerlegung" geantwortet habe. Und Du kannst davon ausgehen, dass ich verstehe wovon ich da geschrieben habe. Sonst hätte ich (wie an anderer Stelle) gesagt, dass ich dazu mangelns Kenntnissen nichts sagen kann.
Nein, ist mir nicht entgangen. Du hast behauptet ich würde nur aus Kosten-Nutzen-Sicht argumentieren. Tue ich nur gar nicht. Zumindest nicht ausschließlich. Das zeigt ja jetzt nur, dass du gar nicht verstanden hast, was ich geschrieben habe. Wie wäre es nochmal mit nachlesen bzw. nachfragen?

Was ist der andere Teil? Der Skill der Programmierer?
Skill ist ein Teil dessen, ja.

Noch einmal: Ich behaupte nicht, dass DX12 für jeden Anwendungsfall besser wäre, sondern nur dass bei hinreichenden Kenntnissen und Fähigkeiten seitens der Programmierer eine hardwarenähere Programmierung ein besseres Endergebnis liefert als eine abstraktere (aufgrund der Limitationen eines Compilers).
Das ist aber leider immer noch falsch. Ein alter Irrglaube, aber immer noch falsch.

Ob der dafür notwendige Aufwand gerechtfertigt ist und wie hoch die Steigerung ist, ist eine andere Frage, für die gemachte Aussage in ihrem Abstraktionsgrad aber auch nicht entscheidend.
Der Aufwand und die Kosten-Nutzen-Rechnung kommen noch zusätzlich zum grundsätzlichen Problem hinzu. Es hat eben seinen Grund, warum Assembler faktisch ausgestorben ist.

Und wo doch LL deiner Meinung nach so der große heilige Gral ist: Warum werden dann die ganzen Spiele im CPU-Limit nicht auf Assembler umprogrammiert? Da liegt doch massig Potential brach ;D

Deine Behauptung kann man hier 1:1 übertragen. Trotzdem sieht man null Assembler. Warum wohl?

Zählen kannst du also auch nicht... respekt.
Textverständnis kannst du also auch nicht ... respekt.

Dann zähle mal die gammeligen DX12 Umsetzungen auf die bei GCN schlecht laufen? Mir fällt nur Deus Ex ein welches zwar eine höhere Framerate mit DX12 liefert, im Spiel aber recht schlechte Frametimes. Bei DX11 ist es aber auch nicht wirklich besser was Frametimes angeht. Bei BF1 @GCN und DX12 kenne ich den aktuellen Stand nicht. Frames sind höher, Frametimes Fragezeichen. Keiner meldet sich diesbezüglich zu Wort.
Min FPS sind bei BF1 deutlich schlechter unter DX12, auch bei AMD. Siehe dazu unzählige Reddits.

Dann gäbe es da noch Total War.

Kleine Übersicht:
http://www.pcgameshardware.de/DirectX-12-Software-255525/Specials/Direct-X-11-Vulkan-1218975/

Der heilige Gral, wie ihr hier darstellen wollt, ist LL auf keinen Fall.

[dargo]

Kleine Übersicht:
http://www.pcgameshardware.de/DirectX-12-Software-255525/Specials/Direct-X-11-Vulkan-1218975/

Der heilige Gral, wie ihr hier darstellen wollt, ist LL auf keinen Fall.
Das ist Stand Januar 2017.

Das ist aber genau mein Argument, dem sich hier heftig widersetzt wird ;)

Welches Argument? Dass nur AAA-Titel low level bieten werden? Dann liegst du hier auch daneben.
http://www.phoronix.com/scan.php?page=news_item&px=Ballistic-Overkill-Vulkan
https://www.reddit.com/r/EscapefromTarkov/comments/645exq/devs_have_working_vulkan_api_build_woohoo/
https://www.gamingonlinux.com/articles/geocore-another-six-degrees-of-freedom-shooter-has-linux-vulkan-support.9973
http://roblox.wikia.com/wiki/Graphics_settings
https://skidrowgamesreloaded.com/the-turing-test-codex/

[gravitationsfeld]

Bucklew, gut, dass du nicht entscheidest wer welche API verwendet.

[Troyan]

Gut, dass der PC-Kunde entscheiden kann, welche korrupte Firma (z.B. die, die über Twitter AMD Karten verkaufen und sich selbst abklatschen, weil man nVidia absichtlich einbremst... Lmao) man nicht unterstützen sollte.

Ansonsten hat das schon lange hier auch nichts mehr mit dem Thema zu tun.

[Gimmick]

Also wenn eine Spieleschmiede nicht mal ihren CPU-Part als gutes MT hinkriegt, sollen die gleichzeitig ihre Grafik-API fast vollkommen selbst in den Griff kriegen?


Besseres MT durch LL API ist O-Ton Entwickler.


Sorry, aber das passt nicht. Auf der einen Seite völlige Dilettanten, aber dann die Götter auf Grafikseite? Glaube ich nicht dran, sorry.

Habe nicht und würde nie von Dilettanten reden.

[dargo]

Gut, dass der PC-Kunde entscheiden kann, welche korrupte Firma (z.B. die, die über Twitter AMD Karten verkaufen und sich selbst abklatschen, weil man nVidia absichtlich einbremst... Lmao) man nicht unterstützen sollte.

Troyans Logik...

* Nvidia verwendet im Gameworks-Titel X hohe Tess.-Faktoren um vorallem AMD auszubremsen = AMD ist schuld, weil Tessellator zu langsam
* Entwickler X arbeitet eng mit AMD zusammen der auch fähig ist GCN Features zu verwenden = Entwickler ist korrupt

;D ;D ;D

btw.
Soll ich dann hier die ganzen Entwickler aufzählen die korrupt sind weil sie eng mit Nvidia die letzten Jahre gearbeitet haben und es immer noch tun? :freak:

[Bucklew]

Das ist Stand Januar 2017.
Na und? Das ändert am konkreten Problem von LL-Apis gar nichts.

Welches Argument? Dass nur AAA-Titel low level bieten werden? Dann liegst du hier auch daneben.
Schön, dass ich wie üblich richtig liege, denn das habe ich nicht behauptet.

Möchtest du nicht wenigstens mal versuchen zu verstehen, was ich schreibe, statt das Forum mit Troll/Spam-Postings zu fluten? :rolleyes:

Bucklew, gut, dass du nicht entscheidest wer welche API verwendet.
Wollte gerade deinen vielfältigen Argumente widerlegen - da fiel mir doch glatt auf, dass da irgendwie keine sind :ugly:

Besseres MT durch LL API ist O-Ton Entwickler.
Was heißt denn nun bitte konkret "Besseres MT"? Die Engine kann auch völlig unabhängig von DX11, 12 oder Vulkan ein MT-Problem haben, wenn der Entwickler nicht vernünftig gearbeitet (= ausreichend Threads implementiert hat). Das hat mit der grundsätzlichen Grafik-API nichts zu tun.

[Gimmick]

Was heißt denn nun bitte konkret "Besseres MT"? Die Engine kann auch völlig unabhängig von DX11, 12 oder Vulkan ein MT-Problem haben, wenn der Entwickler nicht vernünftig gearbeitet (= ausreichend Threads implementiert hat). Das hat mit der grundsätzlichen Grafik-API nichts zu tun.

So einfach ist das wohl nicht. Scheinbar gibt es Einschränkungen durch die API.
Hab das damals(tm) gelesen und mir nicht im Detail gemerkt.

Ich steck da nicht tief in der Materie drin, ich plapper nur nach was die betreffenden Leute von sich geben ^^.

[pixeljetstream]

Bucklew, wie von Kriton gesagt, es sind zwei unterschiedliche Themen:

A) Deine Aussage wie LL Api = teurer für Entwickler, also unrealistisch dass es effektiv viel bringt also dx12 Scheiße, ist doch unabhängig von den technischen Möglichkeiten die die Api bietet.

B) Die Aussagen der anderen = neuere API erlaubt langfristig bessere Nutzung, weil näher an der Hardware. Das heißt nicht dass heute alle dx12/vk renderer ein Erfolg sind (das galt bei dx9 nach dx10 ja auch, dann kam dx11 und irgedwann hatten die leute den dreh raus).

zu B)
Wie ich vorher ausführte, jede API ist ein Sammelsurium an HL und LL Abstraktionen. Dein Assembler Vergleich ist so nicht wahr. DX12/Vk sind immer noch so abstrakt dass die Entwickler damit viele Hersteller erreichen können, natürlich haben die unterschiedliche Vorlieben bei einigen Patterns, aber im Prinzip haben sie die bei Dx11/OpenGL auch.
Ich würde behaupten Konsolenapis sind "low level", weil sie im Normalfall eben in Teilen gar nicht portierbar sind und man den Entwicklern Features und Tools an die Hand gibt die eben genau für eine Architektur gelten.
Das ist bei PC aber nicht der Fall, alles ist viel variabler.
Hast Du selbst Erfahrung im Umgang mit diesen Apis und verschiedenen Hardware Plattformen?

Du ignorierst komplett dass die neuen Apis in ihrem design MT Nutzung deutlich erleichtern. In OpenGL ist das praktisch nicht in dem Maße performant machbar (und ich sage das als Mitarbeiter der Firma die weiß Gott mehr in GL investiert hat als jede andere).
Es ist ein Unterschied ob der Treiber die anderen Threads für Hintergrundoptimierungen nutzt, oder der Entwickler selbst die Arbeit zum Erstellen der Commandbuffer parallelisieren kann. Auch wenn man als Hersteller viel mit solchen Optimierungen rausholen kann, so sind den alten Apis Grenzen gesetzt (single threaded performance) bzw. man muss ja etwas "erkennen" was der Entwickler eigentlich vorhat. In den neuen Apis gibt man den Entwicklern mehr Möglichkeiten explizit zu sein. Denn dieses "erkennen" muss ja auch irgendwo geleistet werden.

Wenn wir an die "Ur" High-Level API gehen, good old OpenGL 1
glBegin(GL_TRIANGLES)
glVertex3f
...
glEnd()

einfacher gehts für den Entwickler ja nicht, aber hier nehme ich mal an, dass Du froh bist, dass die Entwickler das nicht mehr nutzen, da hilft dann selbst die stickstoff übertaktete CPU nicht mehr ;) bzw. greifst zur Quadro, dann bezahlst Du aber eben auch für den "Aufwand" uralte Programme halbwegs performant laufen lassen zu können.

Weder dx11 ist das Maß der Dinge, noch dx12, es wird immer fröhlich weiter gehen. Auch ist nicht jede Abstraktion für alle gleich gut. Vulkan ist von mehreren Herstellern beeinflußt wurden die schon mit dx12 erfahrung hatten und dementsprechend ist das wieder leicht anders.
Metal ist meine ich sogar von den ex-AMDlern die tragende Rolle bei Mantle hatten, mitgemacht worden, und ist wieder anders...

zu A)
In dem Punkt, dass es eine breites Spektrum an Entwicklern gibt, stimme ich Dir zu, nicht umsonst greifen ja viele zu den großen Game-engines und umgehen damit die api diskussion komplett. Aber wie gravitationsfeld sagt, dass ist doch die Entscheidung der Entwickler selbst.

Ich glaube einige Topentwickler, weil sie auf so ähnlichen Konsolen unterwegs waren, und weil sie quasi keine Konsolenequivalente Docu zu NV Architektur hatten, gingen zu sehr davon aus dass einige Sachen so verschieden wohl nicht sein werden. Sie haben imo hier ein paar Verantwortlichkeiten bei der hohen Variabilität unterschätzt. Weswegen denke ich Apple bei Metal auch etwas zurückgerudert hat in Sachen Abstraktion. Deswegen ist aber nicht alles in dx12 schlecht, oder die Tatsache dass es die Notwendigkeit dafür gibt APIs zu erneuern. Es muss immer vorwärts gehen und irgendwo muss man den Schlussstrich ziehen und sagen ship it.

Aber das ist eben "normal", alles inkrementelle Prozesse, Design Iterationen... Manche hier argumentieren als wäre der Jetzt-zustand das absolute beste überhaupt und von allen genau so perfekt geplant. Und es ist doch auch nix eingefroren, sowohl hw also auch sw entwickeln sich doch immer weiter. In vielen Teilbereichen mal auf, mal ab.

Ich finde den Vortrag von Andrew Lauritzen, ex Intel, jetzt EA's Forschungsteam, interessant http://openproblems.realtimerendering.com/s2017/04-Future%20Compute%20SIGGRAPH%202017.pptx
Im Prinzip fordert er auch neuen Fokus auf Abstraktionen, wie HL/LL sollen die Interfaces der Programmiersprachen sein damit sie für die Industrie bezahlbar sind.

Es ist alles grau bzw. bunt :) dieses s/w denken bringt doch nix.

Am Ende wissen doch nur die Hersteller selbst was wirklich in einer api für sie low/high level ist. Und die anderen wissen das zum Teil auch. Wenn sowas wie Vulkan entsteht, muss man ja Abstraktionen finden mit denen alle halbwegs Leben können. Das läuft dann schonmal kooperativ ab, dass der eine Hersteller dem anderen hilft oder Tips bei der Implementierung gibt. Natürlich versucht jeder das beste für sich rauszuholen aber manchmal muss man halt mit nem Feature leben was doof für die eigene Hardware ist. Und an dem Tisch sitzen ja ein paar mehr Hersteller, als die üblichen zwei. Selbst wenn nur ein 3D Hersteller da ist, wie bei Konsolen, will der Platformhalter auch mitreden wie abstrakt alles sein soll. Ich war selbst bei den Anfängen von nvn und vulkan dabei und programmierte benchmark/api usability tests in opengl, opengl+nv extensions, vulkan, nvn. Ein olles CAD Model war eins der ersten größeren modelle die auf der konsole gerendert wurden (schöner cpu overhead test wegen all der kleinen Teile und netter Wettstreit der Treiberteams) ;)
https://github.com/nvpro-samples/gl_vk_threaded_cadscene/raw/master/doc/sample.png

Die Treiberentwickler halten die Apis so gar nicht für low level, für die ist das eher ihr Treibercode. Der Hardwaredesigner hält die Treibercommandos für high level, und sein Scheduler für die Drawcalls für Low Level, der nächste Typ baut dafür die Subunits, und am Ende muss irgendwer das ganze in Hardware gießen ;) Genauso funktioniert es in die andere Richtung, wenn ein Java programmierer in c/c++ memory selbst allokieren muss, ist das schon low level.

[Bucklew]

A) Deine Aussage wie LL Api = teurer für Entwickler, also unrealistisch dass es effektiv viel bringt also dx12 Scheiße, ist doch unabhängig von den technischen Möglichkeiten die die Api bietet.
Ist nur ein Teil meines Argumentes. Ich halte es für Blödsinn über die theoretischen Möglichkeiten als unumstößliches Gesetz festzuhalten, wenn die praktische Umsetzung offensichtlich schwieriger ist, als es hier dargestellt wird. Ein große Menge an gammeligen LL-Ports zeigt das doch.

Einfach zu sagen "LL bietet mehr Potential" ist a) nicht möglich und b) angesichts dieser Fakten einfach viel zu einfach, unreflektiert und dogmatisch.

Und kein IHV oder Spieleentwickler ist "gut" oder "schlecht", jenachdem ob er LL oder HL API bevorzugt. Das sind individuelle Entscheidungen, die auch aus jeder Perspektive Sinn ergeben.

B) Die Aussagen der anderen = neuere API erlaubt langfristig bessere Nutzung, weil näher an der Hardware. Das heißt nicht dass heute alle dx12/vk renderer ein Erfolg sind (das galt bei dx9 nach dx10 ja auch, dann kam dx11 und irgedwann hatten die leute den dreh raus).
Assembler erlauben auch eine bessere Nutzung, weil näher an der Hardware. Wie hoch ist heute der Anteil an Assemblercode in AAA Spielen? 0%? Warum wohl?

Ich komme aus der CPU-Codierung und wie oft musste ich mir schon von nem Informatiker erzählen müssen, wie viel schneller und effizienter sein tolles Assembler-Programm war - tja, blöd, ein einfach Nachbau mit 10 Zeilen C oder C++ Code war schneller. Warum? Weil der Compilerentwickler einige mathematische Tricks kannte, die den AssemblerCode zwar aufgebläht, aber eben auch 10x so schneller gemacht haben.

Das gleiche Problem sehen wir und werden wir bei den LL APIs sehen. Da werden wir auch die Experten sehen die, wie hier im Thread, einfach nur denken LL = besser und damit grandios auf die Fresse fliegen. Wenn es schon Entwicklungsstudios wie DICE nicht vernünftig hinkriegen, wie sollen es dann kleinere Studios schaffen?

Ich prophezeie, dass mit LL die IHV-Bindung noch stärker wird, als es sie heute ist. Einfach weil die Verlagerung der Entwicklungsarbeit bedingt, dass der IHV sein Wissen und Erfahrung früh einbringen muss, statt es wie heute im Treiber zu optimieren.

Ach so und die Menge der gammeligen LL-Pfade, bei denen man sieht wie viel runder DX11 läuft, werden ersetzt durch LL-only und dann läuft das Spiel immer gammlig.

Schöne neue Zukunft.

PS: Die Präsentation schaue ich mir mal in Ruhe an, heute wahrscheinlich keine Zeit.

[Mancko]

Ich prophezeie, dass mit LL die IHV-Bindung noch stärker wird, als es sie heute ist. Einfach weil die Verlagerung der Entwicklungsarbeit bedingt, dass der IHV sein Wissen und Erfahrung früh einbringen muss, statt es wie heute im Treiber zu optimieren.


Das ist sowieso fakt. Das haben aber offensichtlich noch einige nicht gecheckt. Der Spielemarkt wird durch DX12 bzw. Low-Level APIs sehr viel mehr segmentiert werden und es wird dadurch für die IHVs im Nachgang später auch schwerer mögliche suboptimale Ergebnisse nochmal umzubiegen. In der Vergangenheit wurde ein Großteil der Arbeit im Treiber erledigt und es war auch einfacher möglich ein Game auch in einer sehr späten Phase der Entwicklung noch ordentlich zu optimieren oder auch nach dem Verkaufsstart noch.

Das wird sich definitiv ändern. IHVs werden und müssen frühzeitig Einfluss auf die Anpassung und Optimierung nehmen. Sprich die werden sich ihre Spiele und GameStudios bzw. Publisher herausssuchen und dort dann die Leute vor Ort schicken. Heraus kommt dann ein Spiel, dass mal bei dem einen und mal bei dem anderen besser bzw. schlechter läuft. Derjenige bei dem es dann schlechter läuft wird im Nachgang nur sehr schwer das noch verbessern können. Wir werden also mit an zu 100% grenzender Wahrscheinlichkeit noch viel mehr als in der Vergangenheit sehen, dass man die Grafikkarte nach den Spielvorlieben kaufen muss. Das wird sich gar nicht vermeiden lassen. Es ist einfach komplett naiv zu glauben, dass sich Entwicklerstudios bzw. Entwickler bei dem Kosten und Zeitdruck intensiv mit den Architekturunterschieden und Features der einzelnen IHV Hardware auseinander setzen. Das machen die nicht und so werden halt die IHVs mehr machen müssen und das wird eben den Markt weiter segmentieren.

Leider ist das für den Käufer nur schwer vorhersehbar, denn Partnerschaften zwischen IHV und Gamestudio bzw. Publisher ändern sich auch mal über die Zeit. So kann es sein, dass die ersten Spiele eines GameStudios bzw. Publishers sehr gut auf der eigenen Hardware laufen und dann wenn sich die strategischen Partnerschaften mal ändern plötlzich nicht mehr. Daran führt m.E. kein Weg vorbei und insbesondere Nvidia wird auf Grund der finanziellen Möglichkeiten sich dort auch weiter massiv einbringen. Das wird man insbesondere dann merken wenn es um neue Spiele geht und auch um Spiele die jetzt nicht zwingend zu den High Profile Games / AAA Games gehört die jeder kennt.

[Kriton]

Edit: Mit Blick auf pixeljetstreams Post füge ich nichts mehr hinzu.

[Achill]

[..]
Ich komme aus der CPU-Codierung und wie oft musste ich mir schon von nem Informatiker erzählen müssen, wie viel schneller und effizienter sein tolles Assembler-Programm war - tja, blöd, ein einfach Nachbau mit 10 Zeilen C oder C++ Code war schneller. Warum? Weil der Compilerentwickler einige mathematische Tricks kannte, die den AssemblerCode zwar aufgebläht, aber eben auch 10x so schneller gemacht haben.

Das gleiche Problem sehen wir und werden wir bei den LL APIs sehen. Da werden wir auch die Experten sehen die, wie hier im Thread, einfach nur denken LL = besser und damit grandios auf die Fresse fliegen. Wenn es schon Entwicklungsstudios wie DICE nicht vernünftig hinkriegen, wie sollen es dann kleinere Studios schaffen?
[..]


Das ist nicht! das gleich Problem. Darum kann auch sprachlich nicht von einer Aussage A auf B schließen.

--
BTT: Es ging um GameWorks. Die ganze HL vs. LW Diskussion ist interessant aber was hat dies mit GameWorks zu tun.

Einige Fakten/Streitpunkte zu GameWorks waren:
- Ist proprietär, kann Closed-Source sein (war es zumindest früher wo es noch nicht diese feste Marktverteilung gab)
- Sofern Quellcode vorliegt sind Änderungen wenn überhaupt nur unter strengen Auflagen erlaubt. (z.B. darf die Performance von NV GPU nicht schlechter werden, die Änderungen müssen an NV gehen, niemanden Einsicht in die überlassenen Teile von NV-Code geben, ...)
- GameWorks verwendet NvAPI & Extentions - wie sieht der Fallback für nicht NV-Hardware aus, welche realistischen Möglichkeiten bestehen für die anderen Marktteilnehmer den Fallback für sich zu verbessern.

Ansonsten noch ein paar andere Dinge:
- Die Verwendung von GameWorks erkennt man nicht daran, dass *.dll Dateien im Verzeichnis liegen. Aktuelle Spiele scheinen (wahrscheinlich schon für den Kopierschutz) sämtliche benötigten Object-Dateien statisch zu Verlinken - es gibt also nur eine "exe".
- https://github.com/nvpro-samples ist nicht GameWorks (just saying)

[Troyan]

Bingo Mancko. DX12 und Vulkan erlauben das absichtliche Einbremsen von Hardware ohne eine Möglichkeit der (Treiber-)Behebung. Wir sehen es in Gaming Evolved Spielen wie Deus Ex, Civ6, Ashes, Doom... dass der "Low-Level"-API-Pfad miserabel auf nVidia-Hardware läuft und es auch keine nachträgliche Anpassung gibt.

Es segmentiert massiv den PC-Markt ohne dass es einen erkennbaren positiven Effekt gibt. Diese Spiele sehen nicht besser aus, sie laufen nicht besser.

Es fehlt vor Allem bei DX12 ein Leuchtturm-Spiel. Ein Spiel, dass wirklich einen erkennbaren Nutzen zeigt. Und das ist das fragwürdige: Statt Zeit in bessere Grafik zu investieren, wird Zeit in etwas verschwendet, dass nur deswegen implementiert wird, weil ein Grafikkartenhersteller kein Geld für vernünftige DX11 Treiber hat. Bizarr und absurd bilden hier eine perfekte Symbiose.

[Digidi]

Bingo Mancko. DX12 und Vulkan erlauben das absichtliche Einbremsen von Hardware ohne eine Möglichkeit der (Treiber-)Behebung. Wir sehen es in Gaming Evolved Spielen wie Deus Ex, Civ6, Ashes, Doom... dass der "Low-Level"-API-Pfad miserabel auf nVidia-Hardware läuft und es auch keine nachträgliche Anpassung gibt.

Es segmentiert massiv den PC-Markt ohne dass es einen erkennbaren positiven Effekt gibt. Diese Spiele sehen nicht besser aus, sie laufen nicht besser.

Es fehlt vor Allem bei DX12 ein Leuchtturm-Spiel. Ein Spiel, dass wirklich einen erkennbaren Nutzen zeigt. Und das ist das fragwürdige: Statt Zeit in bessere Grafik zu investieren, wird Zeit in etwas verschwendet, dass nur deswegen implementiert wird, weil ein Grafikkartenhersteller kein Geld für vernünftige DX11 Treiber hat. Bizarr und absurd bilden hier eine perfekte Symbiose.

:facepalm:

DX12 Bremst die Hardware nicht ein. DX12 Ruft Hardware Features ab die Nvidia so auf Ihren Karten nicht hat. Deshalb läuft es bei Nvidia langsamer. Nvidia hat Jahre lang auf DX11 und ihren Game Works hin optimiert.

Was ich als sehr clever erachte aber nicht als Förderlich für uns Kunden. So hat man einen Chip gebaut der zwar sehr gut in x64 Tesselation ist, aber x64 Tesselationen eigentlich kaum einen optischen Mehrwehrt bietet. Nur dank Gameworks wird das massiv verwendet und man lässt so die Konkurrenz alt aussehen. Ich glaube Nvidia plant jedes Jahr ein neues unnützes Feature in Ihren Chip ein, nur um es dann mit Gameworks dieses Feature nutzen zu können und um die Konkurrenz alt da stehen zu lassen. Lieder verschenkt Nvidia so auch wertvolle Chipfläsche für unnötige Features und wir könnten deshalb schon viel weiter sein in der GPU Leistung.

Wenn dann Bremst Nvidia AMD aus, weil diese noch auf alten Standards setzt die die AMD Hardware nicht richtig auslasten können. Der Draw Call Test hat es ja gezeigt das beide Ordentlich zulegen, nur AMD legt mehr zu weil sie es richtig in Hardware gegossen haben und Nvidia sieht hier die Rücklichter.

P.s. Und Leuchtturmspiel, Doom und Ashes of Singularity sind also kein Leuchtturm spiel mit den ganzen Effekten und netter Grafik und das bei sogar spielbaren FPS im Gegensatz zu so manchem Gameworks Spiel (Hust: Assasins Creed)


@Achill
Ich finde Schon das die Low Level APIs hier mit reingehören. Sie sind ja mit ein Grund warum Nvidia Gameworks propagiert, weil man in DX12 nur gemächlich zulegen kann. Ich hoffe ja mal das es irgendwann eine Standartisiert API gibt die von "UNABHÄNGIGEN QUELLEN" earbeitet wird und an denen sich dann die Programmierer und Hardwarehersteller orientieren sollen.

[pixeljetstream]

Wie Achill meint, evtl besser nen eigenen Thread aufzumachen.
Andererseits gibt es schon eine Themenüberlappung. GameWorks oder andere Technologie die man lizensiert (gibt ja zig proprietäre Middleware) sind meist HL Lösungen die zur Produktentwicklung beitragen.
Manche sind der Auffassung ein HW Herstelller darf keinen Wert über den Treiber hinaus leisten, die Wertschöpfung darüber soll allein bei Softwarefirmen dann stattfinden. Das macht per Definition die Hardware nicht so wertvoll und austauschbarer/billiger.
Andere sehen es ganzheitlicher, eher auf das Endresultat und darin kein Problem, wer nun welchen Anteil in welcher Phase der Entwicklung hatte. Es ist ein "freier" Markt, es war AMDs stratgische Entscheidung mit GCN eine Konsolenfreundliche Architektur zu bauen und sich von der Abstraktion in dx11 deutlicher zu entfernen. Das muss man technisch anerkennen, gleichzeitig muss man aber auch anerkennen das NVs investments jenseits von Gaming, weniger Verbreuch, oder eben mehr im "Jetzt" (zo GCN1 zeiten) mit dem starken dx11 Optimierungsfokus, eben auch gut gefahren ist. Mehr finanzielle Reserven zu haben um auf Druck oder Chancen einzugehen.

Bucklew, die Kritik ist nicht in erster Linie an Deiner Argumentation auf eines der Themen (wirtschaftlichkeit, breites Spektrum...) sondern dass Du beides vermischt. Du schreibst zu Recht dass nicht alles automatisch über Nacht besser ist, dass die Verantwortung Geld kostet usw. aber Du solltest dann eigentlich auch den Umkehrschluss zulassen dass nicht alles an den neuen APIs schlechter ist. Du klingst in dem Punkt genauso starr wie Du es den anderen vorwirftst. Konkret bei Vulkan und Dx12 können nur Entwickler die wirklich damit arbeiten einschätzen, welche Teilfeatures der APIs sich wie für sie auswirken. Nur Experten wissen was im Detail langsamer oder schneller in der einen oder anderen API ist. Diese Diskussion findet hier aber gar nicht statt, aus Mangel an solchen Personen die das wirklich beurteilen können.

[TGKlaus]

Bingo Mancko. DX12 und Vulkan erlauben das absichtliche Einbremsen von Hardware ohne eine Möglichkeit der (Treiber-)Behebung. Wir sehen es in Gaming Evolved Spielen wie Deus Ex, Civ6, Ashes, Doom... dass der "Low-Level"-API-Pfad miserabel auf nVidia-Hardware läuft und es auch keine nachträgliche Anpassung gibt.


Das liegt daran, das NVidia nicht fähig ist, eine ordentliche Umsetzung von DX12 in Hardware zu bieten.
Für manches gibt es Softwarekrücken und andere Sache, wie AC, funktionieren gar nicht (oder sind nur auf dem Papier implementiert).

[pixeljetstream]

DX12 Bremst die Hardware nicht ein. DX12 Ruft Hardware Features ab die Nvidia so auf Ihren Karten nicht hat.
...
Tessellationskritik, unbruchbares Feature blah
...
Ich hoffe ja mal das es irgendwann eine Standartisiert API gibt die von "UNABHÄNGIGEN QUELLEN" earbeitet wird und an denen sich dann die Programmierer und Hardwarehersteller orientieren sollen.

Tessellation war ein Dx11 Feature, Du willst NV im nachhinein einen Strick drehen, dass sie für das Standard Feature eine sehr gute Implementation hatten? Ein feature in dem es intern weniger um Tessellation als um loadbalancing in der Grafikpipeline über den Chip geht (etwas was AMD mit Vega nun auch in seinem Whitepaper bewirbt).

Darf man immer nur so gut sein wie die Konkurrenz? wenn sie "weniger" gemacht hätten, würden die Leute sagen, ach NV schon wieder implementiert die Standards scheiße usw.

Daran sieht man doch super wie Fans das gleiche Argument einmal für die eigene Seite akzeptieren (async compute als dx12 feature) und einmal verteufeln (tessellation in dx11).

Dieses unabhängige Gremium ist doch weltfremd, wieso sollen SWentwickler allein den Hardwarefirmen vorschreiben wie sie ihre Investitionen zu tätigen haben. Idealerweise sitzen die Leute gemeinsam am Tisch, Firmen wie Epic sind z.b Khronosmitglieder und haben ein Stimmrecht. All diese Standards fallen doch nicht vom Himmel, es gibt Austausch zwischen den verschiedenen Parteien. Das passt natürlich nicht ins Feindbild was hier so mancher zeichnet... denn nur mit einer einfachen s/w Welt gibts einfache Lösungen und man brauch nicht viel Verständnis und Expertise.

[dargo]

Diese ganze Tessellationsgeschichte ist eh schon fast Schnee von gestern. Es funktioniert nicht mehr überall. In RotTR verliert Vega mit Tessellation deutlich weniger als GP104. Also muss sich Nvidia was Neues einfallen. ;)

btw.
Wo wird noch außer bei Witcher 3 mit so hohen Tess.-Faktoren gearbeitet? Und damit meine ich relativ neue Titel.

[Gimmick]

Diese ganze Tessellationsgeschichte ist eh schon fast Schnee von gestern. Es funktioniert nicht mehr überall. In RotTR verliert Vega mit Tessellation deutlich weniger als GP104. Also muss sich Nvidia was Neues einfallen. ;)

btw.
Wo wird noch außer bei Witcher 3 mit so hohen Tess.-Faktoren gearbeitet? Und damit meine ich relativ neue Titel.

Wohl bei allen Titeln mit Hairworks, GodRays etc. Also FC Primal, GR: Wildlands .. mehr fällt mir grade nicht ein ^^.

[Digidi]

Re: Diskussion zu nVidias Gameworks Programm und dessen Auswirkungen


Zitat von Digidi
DX12 Bremst die Hardware nicht ein. DX12 Ruft Hardware Features ab die Nvidia so auf Ihren Karten nicht hat.
...
Tessellationskritik, unbruchbares Feature blah (WAS SOLL DAS DAS HAB ICH SO NICHT GESCHRIEBEN!
...
Ich hoffe ja mal das es irgendwann eine Standartisiert API gibt die von "UNABHÄNGIGEN QUELLEN" earbeitet wird und an denen sich dann die Programmierer und Hardwarehersteller orientieren sollen.
Tessellation war ein Dx11 Feature, Du willst NV im nachhinein einen Strick drehen, dass sie für das Standard Feature eine sehr gute Implementation hatten? Ein feature in dem es intern weniger um Tessellation als um loadbalancing in der Grafikpipeline über den Chip geht (etwas was AMD mit Vega nun auch in seinem Whitepaper bewirbt).

Darf man immer nur so gut sein wie die Konkurrenz? wenn sie "weniger" gemacht hätten, würden die Leute sagen, ach NV schon wieder implementiert die Standards scheiße usw.

Daran sieht man doch super wie Fans das gleiche Argument einmal für die eigene Seite akzeptieren (async compute als dx12 feature) und einmal verteufeln (tessellation in dx11).

Dieses unabhängige Gremium ist doch weltfremd, wieso sollen SWentwickler allein den Hardwarefirmen vorschreiben wie sie ihre Investitionen zu tätigen haben. Idealerweise sitzen die Leute gemeinsam am Tisch, Firmen wie Epic sind z.b Khronosmitglieder und haben ein Stimmrecht. All diese Standards fallen doch nicht vom Himmel, es gibt Austausch zwischen den verschiedenen Parteien. Das passt natürlich nicht ins Feindbild was hier so mancher zeichnet... denn nur mit einer einfachen s/w Welt gibts einfache Lösungen und man brauch nicht viel Verständnis und Expertise.

Ich meinte nicht Softwarentwickeler. Du verdrehst hier meine Worte. Ich hab hier nie was von Softwareentwickler geschrieben. Eine API ist auch nicht nur Software sondern eine Software-"HARDWARE" Schnitstelle. Ich habe auch nichts dagegen das Nvidia gutes Tesselation liefert. Nur erkennt man deutlich das man mit 6 Tesselationengines weit über das Ziel hinaus geschossen ist.

Und das du hier Kommentare verzerrst zeigt nicht gerade von Diskussionsgröße. Du kannst gerne sagen das ich Mist schreibe etc. Aber verfremde nicht meine Zitate!

Es müsste unbedingt bei den APIs einen Normenausschuss geben und nein so ein Gremium ist nicht Weldfremd und gibt es schon seit Sehr sehr langer Zeit:
https://de.wikipedia.org/wiki/Deutsches_Institut_f%C3%BCr_Normung

[Kartenlehrling]

Wir hätten vielleicht die Probleme nicht oder wenigsten geringer wenn Nvidia wirklich Multi-GPU und Co-processing auch in Spiele zuläst.
Ich wär der erste der sich eine 1050Ti verbauen würde.

[dargo]

Apropo Entwicklerkorruption. Damit kommt ja Troyan bei low level immer wieder gerne.
https://www.youtube.com/watch?v=UofHpgnWivo#t=18m08s

Jetzt ist also Turn 10 auch schon korrupt. Nur hier ist sicherlich die Welt in Ordnung da es ja Nvidia ist, gell Troyan? ;)

[Grendizer]

Apropo Entwicklerkorruption. Damit kommt ja Troyan bei low level immer wieder gerne.
https://www.youtube.com/watch?v=UofHpgnWivo#t=18m08s

Jetzt ist also Turn 10 auch schon korrupt. Nur hier ist sicherlich die Welt in Ordnung da es ja Nvidia ist, gell Troyan? ;)

Naja... Turn 10 nicht... aber du willst jetzt nicht ernsthaft behaupten, das Microsoft kein gesteigertes Interesse daran hatte Windows 10 irgendwie interessanter als Windows 7 zu machen ? Da sind so ein paar DX12 only Kracher von der XBox nicht das schlechteste.

[dargo]

Weiche jetzt nicht vom Thema ab. :wink:

[Grendizer]

Bei Forza Horizon 3 waren aber angeblich der Kopierschutz (Verschlüsselung) ursächlich für die Scheiss Performance.

http://www.pcgameshardware.de/Forza-Horizon-3-Spiel-57343/News/Performance-Mod-Probleme-neues-DRM-1209021/

Keine Ahnung, was nVidia dabei helfen soll :biggrin: Auf meinem I5-3570K @4,3 Ghz war das Ding lange Zeit wegen Stottern (bei 99% CPU Auslastung) nicht spielbar. Mit dem Ryzen 1700X lief es dann butterweich.

[uweskw]

Tessellation war ein Dx11 Feature, Du willst NV im nachhinein einen Strick drehen, dass sie für das Standard Feature eine sehr gute Implementation hatten? ............

Ich habe da mal eine Frage zu: Du scheinst ja einer der wenigen zu sein die wirklich in der Materie sind.
Stimmt es eigentlich dass NV bei ihrer Unterstützung der Spielehersteller z.B. Tesselation so gesteigert hat, dass man optisch fast keinen Unterschied mehr gesehen hat, aber die Mitbewerber (AMD/Intel) stark ausgebremst?
Und falls das so war: war den Spieleherstellern nicht klar worauf sie sich einliessen?
Oder sind das "urban legends"?

greetz
US

[Digidi]

Ich habe da mal eine Frage zu: Du scheinst ja einer der wenigen zu sein die wirklich in der Materie sind.
Stimmt es eigentlich dass NV bei ihrer Unterstützung der Spielehersteller z.B. Tesselation so gesteigert hat, dass man optisch fast keinen Unterschied mehr gesehen hat, aber die Mitbewerber (AMD/Intel) stark ausgebremst?
Und falls das so war: war den Spieleherstellern nicht klar worauf sie sich einliessen?
Oder sind das "urban legends"?

greetz
US

Der Grund warum er sich mit der Materie auskennt ist, das er für Nvidia Arbeitet ;D

Da wirst du meiner Meinung nach nichts realistisches zu höheren bekommen.

[Gimmick]

Ich habe da mal eine Frage zu: Du scheinst ja einer der wenigen zu sein die wirklich in der Materie sind.
Stimmt es eigentlich dass NV bei ihrer Unterstützung der Spielehersteller z.B. Tesselation so gesteigert hat, dass man optisch fast keinen Unterschied mehr gesehen hat, aber die Mitbewerber (AMD/Intel) stark ausgebremst?
Und falls das so war: war den Spieleherstellern nicht klar worauf sie sich einliessen?
Oder sind das "urban legends"?

greetz
US

Jein.

Es gab Fälle

- bei denen man mit niedrigeren Faktoren kaum einen Unterschied gesehen hat
- man einen Unterschied gesehen hat, aber niedrig oft als besser empfunden wurde (hier im Forum zumindest ^^)
- man direkt einen Unterschied gesehen hat und eine Reduzierung des Faktors auch unschöne Lücken/Geflacker erzeugt hat.
(- bei denen Tesselation gerkeinen Sinn gemacht hat, aber dennoch volle Kanne reingeballert wurde - das war aber kein nV Titel glaub ich :D)

Ist alles dabei.

[Bucklew]

Das ist nicht! das gleich Problem. Darum kann auch sprachlich nicht von einer Aussage A auf B schließen.
Die Probleme HL/LL sind ziemlich verwandt, unabhängig davon, ob es sich um Grafik- oder CPU-APIs handelt.

Bucklew, die Kritik ist nicht in erster Linie an Deiner Argumentation auf eines der Themen (wirtschaftlichkeit, breites Spektrum...) sondern dass Du beides vermischt. Du schreibst zu Recht dass nicht alles automatisch über Nacht besser ist, dass die Verantwortung Geld kostet usw. aber Du solltest dann eigentlich auch den Umkehrschluss zulassen dass nicht alles an den neuen APIs schlechter ist. Du klingst in dem Punkt genauso starr wie Du es den anderen vorwirftst.
Ich bin überhaupt nicht starr. Ich belege sogar mit Beispielen und Beweisen, was ich hier schreibe. Ich sage auch nirgends, dass die neuen APIs nur schlechtes haben, im Gegenteil.

Was ich aber sehr wohl sage: LL-APIs sind kein heiliger Gral und nur über theoretische Betrachtungen kommen wir nicht zu einem sinnvollen Ergebnis.

Tessellation war ein Dx11 Feature, Du willst NV im nachhinein einen Strick drehen, dass sie für das Standard Feature eine sehr gute Implementation hatten? Ein feature in dem es intern weniger um Tessellation als um loadbalancing in der Grafikpipeline über den Chip geht (etwas was AMD mit Vega nun auch in seinem Whitepaper bewirbt).

Darf man immer nur so gut sein wie die Konkurrenz? wenn sie "weniger" gemacht hätten, würden die Leute sagen, ach NV schon wieder implementiert die Standards scheiße usw.
Das ist ja das interessante: Als NVIDIA Tessellation in GameWorks genutzt hat - normales DX11-Feature - und AMD hier ein Leistungsproblem hatte, war das Betrug, man sollte das ganze boykottieren und als Benchmark waren Spiele, die GameWorks genutzt haben, niemals nie zu gebrauchen.

Jetzt kommen die gleichen Leute, die das gesagt haben, plötzlich daher und nutzen Gaming Evolved Titel als Beleg dafür, wie toll DX12 und Vulkan sind ;D

Trolololololol sage ich da nur.

Der Grund warum er sich mit der Materie auskennt ist, das er für Nvidia Arbeitet ;D

Da wirst du meiner Meinung nach nichts realistisches zu höheren bekommen.
Glückwunsch, ich hätte schon gedacht nach dargos Kindereien könnte das Niveau nicht noch tiefer sinken, aber ihr schafft das wirklich noch.

Macht weiter so, dass ihr Leute mit Wissen aus dem Forum mobbt, nur weil sie euer tolles AMD-Weltbild mit Fakten stören.

:facepalm:

[Troyan]

Naja... Turn 10 nicht... aber du willst jetzt nicht ernsthaft behaupten, das Microsoft kein gesteigertes Interesse daran hatte Windows 10 irgendwie interessanter als Windows 7 zu machen ? Da sind so ein paar DX12 only Kracher von der XBox nicht das schlechteste.

DRM.

Quantum Break ist ja auch so ein Vorzeige-Microsoft-Spiel, dass auf nVidia mit DX11 an AMD vorbeiläuft. ;D

Ziemlich absurd die Microsoft-Store-Spiele als Beispiel zu nehmen.

[Digidi]

Glückwunsch, ich hätte schon gedacht nach dargos Kindereien könnte das Niveau nicht noch tiefer sinken, aber ihr schafft das wirklich noch.

Macht weiter so, dass ihr Leute mit Wissen aus dem Forum mobbt, nur weil sie euer tolles AMD-Weltbild mit Fakten stören.

:facepalm:

Wieso mobb ich Ihm hier aus dem Forum? Er versucht doch gerade das Gegenteil mit mir! Ich schätze Ihn, da er Informativ für die Nvidia Seite Beiträgt. Außerdem bin ich auch nicht jemanden der sagt das von Nvidia alles Mist ist. Im Gegenteil der Rasterizer von Nvidia ist outstanding.

Und nur weil er ein Insider ist muss ich Ihn hier jetzt wie eine König behandeln und ihm alles durchgehen lassen? Sorry dann verzichte ich lieber auf dieses Insiderwissen.

[dargo]

Außerdem bin ich auch nicht jemanden der sagt das von Nvidia alles Mist ist. Im Gegenteil der Rasterizer von Nvidia ist autstanding.

Der gehört aber eigentlich verboten, genau wie AC, Shader Intrinsic und FP16 auf GCN. ;)

[Digidi]

Der gehört aber eigentlich verboten, genau wie AC, Shader Intrinsic und FP16 auf GCN. ;)
Deshalb wäre mal eine Normung wichtig. Es gibt so viele Features die wichtig sind von allen Herstellern. Wir alle würden davon profigieren. Natürlich wollen die Hersteller das nicht. Sie geben damit Marktmacht an die Endkunden ab.

Das beste Beispiel ist FP16. Man braucht nicht unbedingt viel FP32 Leistung, vieles deutet drauf hin das FP16 völlig ausreicht. Da FP16 um einiges kleiner ist auf dem CHIP als FP32 könnte man viel mehr Recheneinheiten verbauen und so viel mehr Leistung mit dem CHIP erzielen. Nur will das keiner weil dann verliert man ja seine Alleinstellungsmerkmale.

Und noch mal nur weil jede CPU nun Async Compute, Tesselation etc mit gewissen Instructionen beherschen muss, heißt das noch lange nicht das Nvidia nicht eine besser Async Compute Einheit bauen kann als AMD. Auch als Spieleentwickler würde ich auf die Einhaltung der Normen bestehen. So muss ich meine Leute nicht auf Unterschiedlichen Schulungen für verschieden Effekte schicken und spare so Zeit. So müsste ich z.B. einen Entwickler für Haareffekte einmal zu Gameworks und einmal zu einer TressFX Schulung schicken. Das Kostet unheimlich viel Geld die Schulung und der Arbeitnehmer fällt für eine Woche praktisch aus.

[unl34shed]

So müsste ich z.B. einen Entwickler für Haareffekte einmal zu Gameworks und einmal zu einer TressFX Schulung schicken. Das Kostet unheimlich viel Geld die Schulung und der Arbeitnehmer fällt für eine Woche praktisch aus.

Muss man das? Beide Techniken laufen auf den Karten beider Hersteller.
- Hairworks läuft allerdings auf Grund der hohen Tessellation besser auf Nvidia (Ist Tessellation überhaupt eine geeignete Technik dafür?)
- TressFX hat bei beiden ähnliche Einbußen. Sollte bald eine Version mit FP16 kommen, dann gibt es einen Vorteil für Vega (und Volta?)

[Digidi]

Muss man das? Beide Techniken laufen auf den Karten beider Hersteller.
- Hairworks läuft allerdings auf Grund der hohen Tessellation besser auf Nvidia (Ist Tessellation überhaupt eine geeignete Technik dafür?)
- TressFX hat bei beiden ähnliche Einbußen. Sollte bald eine Version mit FP16 kommen, dann gibt es einen Vorteil für Vega (und Volta?)

Es läuft dann aber nur auf einer gut und es wäre auch Aufgabe des Gremiums zu bestimmen bei welchem Effekt ich mehr Chipfäche Spare bei gleicher Leistung.
Es müsste hier mal ein neutraler Mensch sagen was mehr Chipfläche auf der GPU verbraucht. Die Tesselation Einheiten oder die Shader und danach würde ich dann die Haareffekte auswählen.

Und wie gesagt wenn der Befehlssatz vereinheitlicht würde würdest du sehr viele Entwicklungsarbeit sparen. Wodurch auch in günstigeren Spielen mehr Effekte Einzug halten. Natürlich würden die AAA Titel an Effekten einbüßen.

Das Zauberwort heißt hier Rationalisierung. Zurzeit arbeiten Spielentwickler an zu vielen Fronten.

[uweskw]

Der Grund warum er sich mit der Materie auskennt ist, das er für Nvidia Arbeitet ;D

Da wirst du meiner Meinung nach nichts realistisches zu höheren bekommen.

schön wäre es, wenn die AMD Mitarbeiter hier wenigstens halb so oft vertreten wären. :rolleyes:
Die sind offensichtlich nicht so motiviert, dass sie in ihrer Freizeit hier posten.
Hat AMD nicht in Dresden eine Fab? Wo ist die nächst gelegene von NV nochnmal? :freak:

geetz
US

[Digidi]

schön wäre es, wenn die AMD Mitarbeiter hier wenigstens halb so oft vertreten wären. :rolleyes:
Die sind offensichtlich nicht so motiviert, dass sie in ihrer Freizeit hier posten.
Hat AMD nicht in Dresden eine Fab? Wo ist die nächst gelegene von NV nochnmal? :freak:

geetz
US

Die Fab ist von Global Foundries und soweit ich weiß macht die in Dresden nichts großes für AMD. Aber Nvidia ist ein großes Unternhemn das viele Absatzmärkte hier in Europa hat. Die haben für die ganzen Rechen Cluster und Wissenschaftsserver hier bestimmt große Teams.

Für AMD ist der Markt, da zu geringer Marktanteil, zu klein. Deshalb hält sich AMD auch relative weit fern von Deutschland. AMD kümmert sich eher erst einmal primär um USA China, Indien Russland.

[fondness]

Der gehört aber eigentlich verboten, genau wie AC, Shader Intrinsic und FP16 auf GCN. ;)

Das wohl mächtigste Feature von Vega sind die Primitive Shader. Leider hinkt da AMD wieder mal mit der Software weit hinterher.

[Hübie]

Deshalb wäre mal eine Normung wichtig. Es gibt so viele Features die wichtig sind von allen Herstellern. Wir alle würden davon profigieren. Natürlich wollen die Hersteller das nicht. Sie geben damit Marktmacht an die Endkunden ab.

Das beste Beispiel ist FP16. Man braucht nicht unbedingt viel FP32 Leistung, vieles deutet drauf hin das FP16 völlig ausreicht. Da FP16 um einiges kleiner ist auf dem CHIP als FP32 könnte man viel mehr Recheneinheiten verbauen und so viel mehr Leistung mit dem CHIP erzielen. Nur will das keiner weil dann verliert man ja seine Alleinstellungsmerkmale.

Und noch mal nur weil jede CPU nun Async Compute, Tesselation etc mit gewissen Instructionen beherschen muss, heißt das noch lange nicht das Nvidia nicht eine besser Async Compute Einheit bauen kann als AMD. Auch als Spieleentwickler würde ich auf die Einhaltung der Normen bestehen. So muss ich meine Leute nicht auf Unterschiedlichen Schulungen für verschieden Effekte schicken und spare so Zeit. So müsste ich z.B. einen Entwickler für Haareffekte einmal zu Gameworks und einmal zu einer TressFX Schulung schicken. Das Kostet unheimlich viel Geld die Schulung und der Arbeitnehmer fällt für eine Woche praktisch aus.

Es gibt keine klassischen Schulungen. Du erhälst die Doku und bestenfalls ein Webinar als Entwickler. Und verstehe ich dich richtig dass man mehr FP16 als FP32 benötigt? DAS bezweifle ich doch mal stark. Man kann einiges mit INT8, manches mit FP16 und den Großteil muss man iirc mit FP32 durch rechnen. FP64 ist fürs Gaming bedeutungslos (Star Citizen war afair damit mal angekündigt für LOD weit entferner Welten).
Hast du da andere Informationen oder habe ich das falsch aufgefasst?

[TGKlaus]

Aber Nvidia ist ein großes Unternhemn das viele Absatzmärkte hier in Europa hat. Die haben für die ganzen Rechen Cluster und Wissenschaftsserver hier bestimmt große Teams.

Oder es liegt daran, das Nvidia im großen Maße Leistungen des BBDO Netzwerkes einkauft.

Der deutsche Ableger in Hamburg ist spezialisiert auf (wie nennt man das Neudeutsch?) digitale Kommunikation.

[Digidi]

Es gibt keine klassischen Schulungen. Du erhälst die Doku und bestenfalls ein Webinar als Entwickler. Und verstehe ich dich richtig dass man mehr FP16 als FP32 benötigt? DAS bezweifle ich doch mal stark. Man kann einiges mit INT8, manches mit FP16 und den Großteil muss man iirc mit FP32 durch rechnen. FP64 ist fürs Gaming bedeutungslos (Star Citizen war afair damit mal angekündigt für LOD weit entferner Welten).
Hast du da andere Informationen oder habe ich das falsch aufgefasst?

FP16 und FP32 sind Genauigkeiten. Ob jetzt ein Polygon 0,0001mm weiter Links oder rechts sitzt wirst du nicht bemerken oder ob du dich im raum jetzt 0,00001 Rad wegen Rundungsfehler weniger drehst. FP16 würde ich jetzt aus sicht der Mathematik als Ausreichend Empfinden für Spiele.

Bei Wissenschaftlichen Anwendungen mit vielen Milliarden Itterationsschritten braucht man natürlich FP64. So was braucht man z.B. um die Exakte Laufbahne für den Komenten zu bestimmen.

Da FP16 weniger Stellen hast braucht man dann auch weniger Transistoren für die Berchnungen ;)

[uweskw]

...........Für AMD ist der Markt, da zu geringer Marktanteil, zu klein. Deshalb hält sich AMD auch relative weit fern von Deutschland. AMD kümmert sich eher erst einmal primär um USA China, Indien Russland.

Dann sollte AMD schnellstens lernen wie wichtig Forenarbeit und virales Marketing für den Umsatz/Marktanteil ist.
Für schlappe 300€ pro Woche könnte ich da echt was tun für die. Break-even ist bei nicht mal 50 zusätzlich verkauften Karten im Monat.
Noch effektiver bin ich natürlich wenn ich mit ein paar Insiderinfos versorgt werde. Fantastischer Return on Invest. ;D;D;D

greetz
US

[TGKlaus]

Dann sollte AMD schnellstens lernen wie wichtig Forenarbeit ...

Sorry, aber so genannte "Forenarbeit" sollte aufgedeckt und angeprangert.
Leider sehen das große Forenanbieter anders, da zumeist der Zweck die Monetarisierung ist (auf die eine oder andere Weise ....).

[Troyan]

Es läuft dann aber nur auf einer gut und es wäre auch Aufgabe des Gremiums zu bestimmen bei welchem Effekt ich mehr Chipfäche Spare bei gleicher Leistung.
Es müsste hier mal ein neutraler Mensch sagen was mehr Chipfläche auf der GPU verbraucht. Die Tesselation Einheiten oder die Shader und danach würde ich dann die Haareffekte auswählen.

Und wie gesagt wenn der Befehlssatz vereinheitlicht würde würdest du sehr viele Entwicklungsarbeit sparen. Wodurch auch in günstigeren Spielen mehr Effekte Einzug halten. Natürlich würden die AAA Titel an Effekten einbüßen.

Das Zauberwort heißt hier Rationalisierung. Zurzeit arbeiten Spielentwickler an zu vielen Fronten.

Wow - was du schreibst erreicht nichtmal die Erdoberfläche vom Niveau. Was soll so ein Quatsch? Ein Gremium soll entscheiden, was man in einem Chip bauen soll? Weiß du, dass dies bei DX11 und OpenGL geschehen ist? Und die haben sich FÜR Tessellation mit einem Mindestfaktor von 64 entscheiden - Lmao.
Akzeptiere dies doch einfach. Denke ich immer daran, dass es Menschen gibt, die haben mehr Ahnung vom Thema.

Gott, ich muss immer noch lachen, über den Unsinn. Was passiert eigentlich, wenn dein "neutraler" Gutachter sich für Tessellation entscheiden würde? ;D

[Gimmick]

Tessellation mit einem Mindestfaktor von 64 entscheiden

Höchstfaktor

[Troyan]

Nein, Mindestfaktor. Klingt in Bezug auf Feature_Level 11_0 komisch, aber Mindestfaktor entspricht hier auch Höchstfaktor: https://msdn.microsoft.com/de-de/library/windows/desktop/ff476340(v=vs.85).aspx#Tessellator_Stage

/edit: Es ist in OpenGL "genauer" definiert. Dort entspricht 64 den Mindestfaktor:
In the below discussion, max​ is the maximum allowed tessellation level, as defined by the GL_MAX_TESS_GEN_LEVEL. It must be at least 64, so you have some room to play with.
https://www.khronos.org/opengl/wiki/Tessellation#Tessellation_levels

[Digidi]

Nein, Mindestfaktor. Klingt in Bezug auf Feature_Level 11_0 komisch, aber Mindestfaktor entspricht hier auch Höchstfaktor: https://msdn.microsoft.com/de-de/library/windows/desktop/ff476340(v=vs.85).aspx#Tessellator_Stage

/edit: Es ist in OpenGL "genauer" definiert. Dort entspricht 64 den Mindestfaktor:

https://www.khronos.org/opengl/wiki/Tessellation#Tessellation_levels


Also ich lese hier Tess Faktor Bereich [2..64] Wobei 64 der HÖCHSTFAKTOR ist.


:facepalm:
In the below discussion, max​ is the maximum allowed tessellation level, as defined by the GL_MAX_TESS_GEN_LEVEL. It must be at least 64, so you have some room to play with.

[Troyan]

Richtig: Er ist der definierte Höchstfaktor der Hardware und gleichzeitig der definierte Mindestfaktor der Hardware. Verstehste? Hardware. Soll ich nochmal? Hardware. Jetzt verstanden? Nein, okay: Es ist der Mindestfaktor für die Hardware.

Und was der Text unter Picard soll, verstehe ich nicht. Aber das spielt wohl auch keine Rolle, wenn man Englisch halbswegs versteht...

[Gimmick]

Nein, Mindestfaktor. Klingt in Bezug auf Feature_Level 11_0 komisch, aber Mindestfaktor entspricht hier auch Höchstfaktor: https://msdn.microsoft.com/de-de/library/windows/desktop/ff476340(v=vs.85).aspx#Tessellator_Stage

/edit: Es ist in OpenGL "genauer" definiert. Dort entspricht 64 den Mindestfaktor:

https://www.khronos.org/opengl/wiki/Tessellation#Tessellation_levels

Da ist dein vorheriger Post etwas unklar.
Aber so verstanden will ich nicht widersprechen.

[TGKlaus]

Richtig: Er ist der definierte Höchstfaktor der Hardware und gleichzeitig der definierte Mindestfaktor der Hardware. Verstehste? Hardware. Soll ich nochmal? Hardware. Jetzt verstanden? Nein, okay: Es ist der Mindestfaktor für die Hardware.

Und was der Text unter Picard soll, verstehe ich nicht. Aber das spielt wohl auch keine Rolle, wenn man Englisch halbswegs versteht...

Das Leute so dermassen doof machen, sollte echt mal Konsequenzen haben.

[Locuza]

Es läuft dann aber nur auf einer gut und es wäre auch Aufgabe des Gremiums zu bestimmen bei welchem Effekt ich mehr Chipfäche Spare bei gleicher Leistung.
Es müsste hier mal ein neutraler Mensch sagen was mehr Chipfläche auf der GPU verbraucht. Die Tesselation Einheiten oder die Shader und danach würde ich dann die Haareffekte auswählen.

Und wie gesagt wenn der Befehlssatz vereinheitlicht würde würdest du sehr viele Entwicklungsarbeit sparen. Wodurch auch in günstigeren Spielen mehr Effekte Einzug halten. Natürlich würden die AAA Titel an Effekten einbüßen.

Das Zauberwort heißt hier Rationalisierung. Zurzeit arbeiten Spielentwickler an zu vielen Fronten.
Es gibt abermillionen mögliche Anwendungsfälle für Software und unzählige Hardwareunterschiede zwischen den Herstellern.
Die Vorstellung, dass ein Gremium einen Super-Standard kreieren könnte, wo jeder Anwendungsfall bedacht wurde und "so neutral wie möglich" für alle spezifiziert, ist einfach reine Phantasie.

Wir haben aktuelle Spezifikationen von unterschiedlichen Programmiersprachen und APIs, welche mehr oder weniger gut alles unter einer gewissen Bandbreite unter einem Dach bekommen, was du vorschlägst geht ins völlige Utopia, wo jede Software und Hardware auf einem Punkt landet, unter allen möglichen Bedingungen.

Man kann damit argumentieren, dass die Bandbreite zu groß ausfällt und man den Gurt enger schnallen sollte, so etwas wäre immerhin mit der Praxis bzw. Realität vereinbar.

Wenn sich ein internationales Gremium z.B. für eine Weltsprache bilden würde, wäre ich dem zugeneigt in dem Fall.
Das ist aus heutiger Perspektive aber völlig utopisch.

[Hübie]

FP16 und FP32 sind Genauigkeiten. Ob jetzt ein Polygon 0,0001mm weiter Links oder rechts sitzt wirst du nicht bemerken oder ob du dich im raum jetzt 0,00001 Rad wegen Rundungsfehler weniger drehst. FP16 würde ich jetzt aus sicht der Mathematik als Ausreichend Empfinden für Spiele.

Bei Wissenschaftlichen Anwendungen mit vielen Milliarden Itterationsschritten braucht man natürlich FP64. So was braucht man z.B. um die Exakte Laufbahne für den Komenten zu bestimmen.

Da FP16 weniger Stellen hast braucht man dann auch weniger Transistoren für die Berchnungen ;)

Ich bin kein Dev, aber bezweifle erst mal dass FP16 überwiegend ausreichend ist. Das System ist ja kumulierend und da ist Genauigkeit eben wichtig. Vielleicht mag sich da jemand zu äußern, der Erfahrung hat. ;)

[Digidi]

Es gibt abermillionen mögliche Anwendungsfälle für Software und unzählige Hardwareunterschiede zwischen den Herstellern.
Die Vorstellung, dass ein Gremium einen Super-Standard kreieren könnte, wo jeder Anwendungsfall bedacht wurde und "so neutral wie möglich" für alle spezifiziert, ist einfach reine Phantasie.

Wir haben aktuelle Spezifikationen von unterschiedlichen Programmiersprachen und APIs, welche mehr oder weniger gut alles unter einer gewissen Bandbreite unter einem Dach bekommen, was du vorschlägst geht ins völlige Utopia, wo jede Software und Hardware auf einem Punkt landet, unter allen möglichen Bedingungen.

Man kann damit argumentieren, dass die Bandbreite zu groß ausfällt und man den Gurt enger schnallen sollte, so etwas wäre immerhin mit der Praxis bzw. Realität vereinbar.

Wenn sich ein internationales Gremium z.B. für eine Weltsprache bilden würde, wäre ich dem zugeneigt in dem Fall.
Das ist aus heutiger Perspektive aber völlig utopisch.

Du glaubst gar nicht was heutzutage alles Genormt ist und wie Detailliert, ich erwähne nur den maximalen Krümmungsradius der Banane :) . Da wird man das bei einer GPU auch noch hinbekommen. Zumindest die groben Grundzüge. Es soll ja nicht bis ins Detail gehen.

[Locuza]

[...]
Es sollte z.B. nur sein wenn ein Programmierer den Befehl eingibt mach haare dann macht der Haare. Mann kann das ja erst einmal auf eine Hand voll von bekannten Effekten runterbrechen und die GPU muss so gebaut sein das sie diesen Befehl ausführen kann.
Es gibt kein Befehl "mach Haare".
Das Rendering von Haaren besteht aus mehreren Berechnungen und jede davon hat Implikationen für das Hardwaredesign.
Wenn du das Normen möchtest, setzt du Normen für unzählige Faktoren fest, die nicht nur das Rendering von Haaren beeinflusst.
Entsprechend kann auch kein Gremium sich hinsetzen und paar Effekte anschauen und darüber nachdenken, was den der Königsweg für alle wäre, sie hätte immer Millionen Dinge zu beachten und deswegen haben unsere aktuellen Spezifikationen mehrere Schichten an Abstraktionen und häufig einen Funktionsumfang und keine einzeln definierte Punkte, da in der Praxis keine absoluten Wahrheiten für eine Technik existieren.

TressFX und HairWorks laufen beide auf jeder DX11/DX12 fähigen Hardware, da sie entsprechend einer Spezifikation programmiert worden sind, die jeder Hersteller unterstützen kann.
Du scheinst aber ganze Möglichkeiten verbieten zu wollen, damit jeder X-Effekt auf die gleiche Art und Weise umgesetzt wird, das würde in der Praxis niemals funktionieren.

[Digidi]

Es gibt kein Befehl "mach Haare".
Das Rendering von Haaren besteht aus mehreren Berechnungen und jede davon hat Implikationen für das Hardwaredesign.
Wenn du das Normen möchtest, setzt du Normen für unzählige Faktoren fest, die nicht nur das Rendering von Haaren beeinflusst.
Entsprechend kann auch kein Gremium sich hinsetzen und paar Effekte anschauen und darüber nachdenken, was den der Königsweg für alle wäre, sie hätte immer Millionen Dinge zu beachten und deswegen haben unsere aktuellen Spezifikationen mehrere Schichten an Abstraktionen und häufig einen Funktionsumfang und keine einzeln definierte Punkte, da in der Praxis keine absoluten Wahrheiten für eine Technik existieren.
Wie du siehst hab ich es vorher herausgenommen weil es zu unspezifisch war und ich stimme dir da zu.

Wo ich hinaus will, ist das man mehr in diese Richtung forscht und die Randbedingungen eingrenzt. Wie gesagt jede M6 er Schraube passt in ein M6er Loch und die Schraube hat eine Mindestfestigkeit. Natürlich kannst du wenn du willst die Schraube machen wie du willst. Aber du must halt aufpassen das sie die Mindestanforderungen erfüllt und sie immer in ein 6er loch passt.

Es gehören bestimmte Rechenoperationen schon vorhersagen kann ob das Sinnvoll ist oder nicht(Dazu gibt es sogar Mathematische abschätzungen) ;). Beispiel hier wieder FP16 und FP32. Man könnte sich doch hier endlich mal auf ein Format einigen.

Genau so wie bei dem allzeit im Gebrauch befindlichen Kantenglättungsverfahren. Da müsste man nun mal alle am Markt befindlichen Kanteglättungsverfahren im Markt bewerten und dann das Effektifste herausziehen. So könnten sich dann Hardwarehersteller und Spieleentwickler darauf konzentrieren dieses Verfahren noch effizienter zu machen. Wenn ein neues Verfahren rauskommt was besser ist, sollte man es der Normungsbehörde vorlegen. Wenn sie es für Sinnvoll erachtet wird es in die API aufgenommen.

AMD und Nvidia könnten noch immer neue Techniken einreichen die auf Ihrer Hardware am Anfang dann auch gerne mal besser laufen können. Ziel muss es dann aber sein das man der Konkurrenz die Option offen lässt nachzuziehen oder es gar besser zu machen und ganz wichtig wäre ein Ausschuss der Unabhängig die Technologie dann bewertet ob es wirklich so sinvoll ist. Der Beweis müsste natürlich von den Softwareentwicklern oder Hardwarehersteller erbracht werden.

Mantle und Primitive Shader von AMD sind übrigens Dinge die aus den Wünschen der Softwareentwickler gewachsen sind weil sie da auf eine Mauer gestoßen sind. Ein vernünftiger Ausschuss hätte dies Prämisse erkannt und bei den Hardwareherstellern durchgesetzt das hier was am Standard angepasst werden muss.

[AffenJack]

Wo ich hinaus will, ist das man mehr in diese Richtung forscht und die Randbedingungen eingrenzt. Wie gesagt jede M6 er Schraube passt in ein M6er Loch und die Schraube hat eine Mindestfestigkeit. Natürlich kannst du wenn du willst die Schraube machen wie du willst. Aber du must halt aufpassen das sie die Mindestanforderungen erfüllt und sie immer in ein 6er loch passt.


Eine solche Normierung hast du bereits durch die DX12/Vulkan Standards. Deine Vorschläge sind eher im Bereich: Alle Autos haben einen Motor, wir normieren jetzt einen Einheitsmotor und alle müssen sich dem beugen. Es gibt verschiedene Techniken, weil sie verschiedene Vor- und Nachteile haben. Das ist dann bei Kantenglättungstechniken ebenso wie bei der Motoranalogie. Ein solches Gremium was du vorschlägst würde sich noch viel länger um Normen streiten und Innovationen völlig abwürgen. Wozu überhaupt noch verschiedene Engines, wenn alle die gleichen Techniken benutzen? Da würde dann auch ne Einheitsengine ausreichen um das weiter zu vereinfachen.

[Digidi]

Eine solche Normierung hast du bereits durch die DX12/Vulkan Standards. Deine Vorschläge sind eher im Bereich: Alle Autos haben einen Motor, wir normieren jetzt einen Einheitsmotor und alle müssen sich dem beugen. Es gibt verschiedene Techniken, weil sie verschiedene Vor- und Nachteile haben. Das ist dann bei Kantenglättungstechniken ebenso wie bei der Motoranalogie.
Es soll doch noch frei sein wie der Chip aufgebaut ist und was mir an DX12 und Vulkan nicht gefällt ist das es keine Kontrolle durch den Konsumenten gibt sondern die Firmen selbst entscheiden was Sache ist.

Aber gut das du Motoren erwähnst. Auch heute werden die Schnitstellen bei Motoren weit eingeengt dank des Steuergesetzes oder den ganzen Verordnungen. Hubraum Leistung und Verbrauch spielen hier eine große Rolle und sind sehr streng Reguliert. Die Randbedingungen sind hier z.B. Steuern und Normverbräuche die Staatlich geregelt sind und auf die die Autobauer keinen Einfluss haben.

Auch die Autobreiten so wie Reifeneigenschaften sind grob genormt. Ist dir Schon mal aufgefallen das heute kaum noch ein Auto einen Motor hat der Größer als 1,5l ist und die Brenkammer immer so um die 0,5l haben?

Man stelle sich vor die Autobauer könnten bauen was sie wollten

[AffenJack]

Es soll doch noch frei sein wie der Chip aufgebaut ist.

Aber gut das du Motoren erwähnst. Auch heute werden die Schnitstellen bei Motoren weit eingeengt dank des Steuergesetzes oder den ganzen Verordnungen. Hubraum Leistung und Verbrauch spielen hier eine große Rolle und sehr streng Reguliert. Die Randbedingungen sind hier z.B. Steuern und Normverbräuche die Staatlich geregelt sind und auf die die Autobauer keinen Einfluss haben.

Auch die Autobreiten so wie Reifeneigenschaften sind grob genormt. Ist dir Schon mal aufgefallen das heute kaum noch ein Auto einen Motor hat der Größer als 1,5l ist und die Brenkammer immer so um die 0,5l haben?

Man stelle sich vor die Autobauer könnten bauen was sie wollten

Können die Grafikkartenhersteller genausowenig. Es ist durch DX12/Vulkan definiert was das Ding können muss, wenn es ordentlich verkaufen willst. Mehr brauchst du nicht. Du kannst auch eine Grafikkarte bauen, die nicht Polygonbasiert ist oder sonstwas macht. Es bringt aber nix, weil das Ding nicht mit den vorhandenen Normierungen wie DX kompatibel ist und niemand es nutzen wird.
Du verstehst nicht, dass du auf einem viel höheren Level alles normieren willst.

Mir ist gerade aufgefallen, deine Schraubenanalogie da auch genauso passt. Wieso gibt es verschiedene Schraubenköpfe und wieso wurden die nicht abgeschafft? Nach dir müssten die alle weggenormt werden, weil unsinnig. Das passt noch viel besser zu den Kantenglättungstechniken. :wink:

[Digidi]

Für Gameworkseffekte brauchst du doch kein API oder?

Verschieden Schraubenköpfe gibt es noch weil es sinn macht. Weil du z.B. mit einem Flachschlüssel an die Schraube an gewissen Stellen besser ran kommst als mit einem Imbus. Aber es gibt jetzt nicht mehr Schrauben mit Schlüsselweite 22,84 das du dir dann den teuren Spezialschlüssel kaufen must.

Nein ich gehe nicht von einer höheren Abstraktionsebene auf. Je tiefer die Normung sitzt um so besser. Ich glaube z.B. das es ein Optimum auf Frontend-Shader-Backend gibt.

[Locuza]

[...]
Wo ich hinaus will, ist das man mehr in diese Richtung forscht und die Randbedingungen eingrenzt. Wie gesagt jede M6 er Schraube passt in ein M6er Loch und die Schraube hat eine Mindestfestigkeit. Natürlich kannst du wenn du willst die Schraube machen wie du willst. Aber du must halt aufpassen das sie die Mindestanforderungen erfüllt und sie immer in ein 6er loch passt.

Eine M6-Schraube stellt aber eine völlig einfache Norm dar.
Bezogen auf Hairrendering reden wir nicht von genormten M6-Schrauben, sondern von fertigen Häusern.

Es gehören bestimmte Rechenoperationen schon vorhersagen kann ob das Sinnvoll ist oder nicht(Dazu gibt es sogar Mathematische abschätzungen) ;). Beispiel hier wieder FP16 und FP32. Man könnte sich doch hier endlich mal auf ein Format einigen.
Weil das für viele Anwendungsbeispiele unsinnig ist, etwas aufzuwingen, was vielleicht gar nicht nötig ist.
Das ist auch ein Grund wieso OpenCL in naher Zukunft nicht mehr FP32 voraussetzen wird, weil es unsinnig ist, dass jede Hardware den Overhead für 32-Bit Präzision "zahlen" muss, wenn der Anwendungsbereich das gar nicht benötigt.
Mit FP16 kann man auch nicht alles ohne Artefakte berechnen und nicht alles benötigt 32-Bit, entsprechend können beide Genauigkeiten verwendet werden, je nach Fall, wo es Sinn ergibt.

AMD und Nvidia könnten noch immer neue Techniken einreichen die auf Ihrer Hardware am Anfang dann auch gerne mal besser laufen können. Ziel muss es dann aber sein das man der Konkurrenz die Option offen lässt nachzuziehen oder es gar besser zu machen und ganz wichtig wäre ein Ausschuss der Unabhängig die Technologie dann bewertet ob es wirklich so sinvoll ist. Der Beweis müsste natürlich von den Softwareentwicklern oder Hardwarehersteller erbracht werden.
Und in wie fern stellt das ein Board um Microsoft oder die Khronos Group nicht dar?
Tessellation kann von jedem Hersteller so umgesetzt werden, wie es ihm passt, solange er die logische Funktionsweise von der Spezifikation erfüllt.
ARM hat es über Compute-Shader umgesetzt, ohne dedizierte Fixed-Function-Hardware dafür.

Conservative Rasterization ist ein neues Rendering-Feature, welches unter DX12 spezifiziert wurde, jetzt von Nvidia, Intel und neulich AMD unterstützt.

[Digidi]

Eine M6-Schraube stellt auch aber eine völlig einfache Norm dar.
Bezogen auf Hairrendering reden wir nicht von genormten M6-Schrauben, sondern von fertigen Häusern.


Weil das für viele Anwendungsbeispiele unsinnig ist, etwas aufzuwingen, was vielleicht gar nicht nötig ist.
Das ist auch ein Grund wieso OpenCL in naher Zukunft nicht mehr FP32 voraussetzen wird, weil es unsinnig ist, dass jede Hardware den Overhead für 32-Bit Präzision "zahlen" muss, wenn der Anwendungsbereich das gar nicht benötigt.
Mit FP16 kann man auch nicht alles ohne Artefakte berechnen und nicht alles benötigt 32-Bit, entsprechend können beide Genauigkeiten verwendet werden, je nach Fall, wo es Sinn ergibt.


Und in wie fern stellt das ein Board um Microsoft oder die Khronos Group nicht dar?
Tessellation kann von jedem Hersteller so umgesetzt werden, wie es ihm passt, solange er die logische Funktionsweise von der Spezifikation erfüllt.
ARM hat es über Compute-Shader umgesetzt, ohne dedizierte Fixed-Function-Hardware dafür.

Conservative Rasterization ist ein neues Rendering-Feature, welches unter DX12 spezifiziert wurde, jetzt von Nvidia, Intel und neulich AMD unterstützt.

Auch für den Hausbau gibt es garantiert eine Norm. Eher gesagt gibt es hier viele Normen die Baumartig auf sich praktisch aufbauen. Und so wird jeder Zweig erweitert und angepasst mit der Zeit ;) Du kannst gerne mal danach schauen wie viele Normen du erfüllen must nur um das Fundament zu gießen. ;)

Was micht stört ist schon mal das es zwei APIs gibt (mit Konsolen dann sogar schon 5 APIs), anstatts eine. Hinzu kommen die ganzen Erweiterungen außerhalb hinzu die nicht offen Sind. Das kann für uns als Endverbraucher nicht gut sein.

[AffenJack]

Für Gameworkseffekte brauchst du doch kein API oder?

Verschieden Schraubenköpfe gibt es noch weil es sinn macht. Weil du z.B. mit einem Flachschlüssel an die Schraube an gewissen Stellen besser ran kommst als mit einem Imbus. Aber es gibt jetzt nicht mehr Schrauben mit Schlüsselweite 22,84 das du dir dann den teuren Spezialschlüssel kaufen must.

Nein ich gehe nicht von einer höheren Abstraktionsebene auf. Je tiefer die Normung sitzt um so besser. Ich glaube z.B. das es ein Optimum auf Frontend-Shader-Backend gibt.

Jo verschiedene Köpfe haben verschiedene Vorteile, wie verschiedene AA-Techniken eben oder andere Sachen. Deshalb ist es unsinnig beides abzuschaffen wie ich zu erklären versuche. Deine Normierung der Schlüsselweite hast du bei GPUs z.B. eher bei der Normierung von Gleitkommaoperationen.
https://de.wikipedia.org/wiki/IEEE_754

Du willst wie gesagt eine viel höhere Ebene der Normierung die unsinnig ist. Und nein, außer in einer Traumwelt gibt es bestimmt kein optimales Frontend-Shader-Backend.

Aber ich bin hier aus der Diskussion auch raus, denn es ist müßig über etwas zu diskuttieren, was nie auch nur ansatzweise eintreffen wird, weil alle Devs etc. wissen, dass es keinen Sinn macht.

[Digidi]

Jo verschiedene Köpfe haben verschiedene Vorteile, wie verschiedene AA-Techniken eben oder andere Sachen. Deshalb ist es unsinnig beides abzuschaffen wie ich zu erklären versuche. Deine Normierung der Schlüsselweite hast du bei GPUs z.B. eher bei der Normierung von Gleitkommaoperationen.
https://de.wikipedia.org/wiki/IEEE_754

Du willst wie gesagt eine viel höhere Ebene der Normierung die unsinnig ist. Und nein, außer in einer Traumwelt gibt es bestimmt kein optimales Frontend-Shader-Backend.

Aber ich bin hier aus der Diskussion auch raus, denn es ist müßig über etwas zu diskuttieren, was nie auch nur ansatzweise eintreffen wird, weil alle Devs etc. wissen, dass es keinen Sinn macht.

Ich habe auch nicht gesagt das man Altes einfach Abschafft. Ich vermisse den Prozess das Optimum zu finden bei dem ganzen. Das ist es generell was mich stört! Alte Dinge können so lange sie noch sinnvoll sind in der Norm zu bleiben.

Die Normung ging einmal hervor um das Optimum im Prozess zu finden und nicht zu viele auswüchse in alle Richtungen zu haben und das sehe ich hier mit so Dingen wie Gameworks und den ganzen APIs. Immer mehr Auswüchse immer spezieller und die Softwareentwickler wenden es dann kaum noch an weil die Implementierung zu lange dauert und zu Risikobehaftet ist.

Die Schraube hätte sich als Füge teil nie durchgesetzt wenn man es nicht genormt hätte.

[Locuza]

Für Gameworkseffekte brauchst du doch kein API oder?
[...]
Je nachdem, wie der Effekt umgesetzt wurde, brauchst du die entsprechende API bzw. muss deine Anwendung verwenden.
HairWorks gibt es für DX11/12, dagegen wird HFTS bisher über NvAPI umgesetzt (nur von Nvidia unterstützt).

Auch für den Hausbau gibt es garantiert eine Norm. Eher gesagt gibt es hier viele Normen die Baumartig auf sich praktisch aufbauen. Und so wird jeder Zweig erweitert und angepasst mit der Zeit ;) Du kannst gerne mal danach schauen wie viele Normen du erfüllen must nur um das Fundament zu gießen. ;)

Was micht stört ist schon mal das es zwei APIs gibt (mit Konsolen dann sogar schon 5 APIs), anstatts eine. Hinzu kommen die ganzen Erweiterungen außerhalb hinzu die nicht offen Sind. Das kann für uns als Endverbraucher nicht gut sein.
Natürlich auch Unzählige, z.B. wie hoch der Abstand zwischen Treppenstufen sein darf.
Genauso wie bei Tessellation die Norm (unter OGL/DX) existiert, dass mehr als Faktor 64 nicht geht.

Mehrere APIs und herstellerspezifische Erweiterungen kann man natürlich kritisch sehen, solange kein "legitimer" Grund besteht.
Aber ohne Vulkan-Erweiterungen gäbe es unter Doom keine performanten Anpassungen für GCN.
War das schlecht für die Endverbraucher?
Hier möchte man eben das Beste aus seiner Hardware holen oder Erweiterungen als Innovationsvektor verwenden.
Solch Möglichkeiten zu unterbinden, hat dann stellenweise den Nachteil, dass mögliche Funktionen und somit die Hardware, vor sich hingammelt, bis irgendwann mal ein gemeinsamer Standard existiert.

Konsolen verwenden proprietäre APIs, um Entwicklern eine weitreichende Kontrolle über die Hardware zu ermöglichen, dass führt auch zu Code der nicht portabel geschrieben werden kann.
DX12 funktioniert unter Intel, Nvidia, AMD und anderen IHVs, GNM von der PS4 dagegen könnte nur auf AMD funktionieren, weil es zuviele hardwarespezifische Funktionen und Möglichkeiten gibt.

Apple hat Metal spezifiziert, dass können sie ruhig als moderne und einfache API für ihr Ökosystem verwenden, aber Vulkan nicht zu supporten, ist aktuell für Entwickler und Endverbraucher mies.

[Digidi]

Solch Möglichkeiten zu unterbinden, hat dann stellenweise den Nachteil, dass mögliche Funktionen und somit die Hardware, vor sich hingammelt, bis irgendwann mal ein gemeinsamer Standard existiert.

Konsolen verwenden proprietäre APIs, um Entwicklern eine weitreichende Kontrolle über die Hardware zu ermöglichen, dass führt auch zu Code der nicht portabel geschrieben werden kann.
DX12 funktioniert unter Intel, Nvidia, AMD und anderen IHVs, GNM von der PS4 dagegen könnte nur auf AMD funktionieren, weil es zuviele hardwarespezifische Funktionen und Möglichkeiten gibt.

Apple hat Metal spezifiziert, dass können sie ruhig als moderne und einfache API für ihr Ökosystem verwenden, aber Vulkan nicht zu supporten, ist aktuell für Entwickler und Endverbraucher mies.

Das Prolbem ist, dass du einen Unendlichen Informationspool für die Spieleentwickler schaffst, die dann so überfordert sind das sie gar nicht mehr wissen was sie Implementieren sollen und dann die Effekte in Qualität und Quantität sinken.
Über leg dir mal die Resourcen bei EA die alleine dafür aufgebracht werden müssen nur um das Teil auf allen Plattformen mit ihren speziellen APIs lauffähig zu machen.

Du machst fast die gleiche Arbeit theoretisch mehrmals um es auf allen 5 Systemen zum laufen zu bekommen. Diese Zeit hätte der Spieleentwickler schon in neue Effekte stecken können.

[Bucklew]

Es ist schon echt lustig. Vor >10 Jahren wurde FP32 (teilweise) zur Pflicht für DirectX9-kompatible Grafikkarten, dito war DX9 damals schon HighLevel. Damals war es ein Marktingargument, FP32 vollkommen zu unterstützen und wir Spieler waren froh von den ganzen IHV-eigenen APIs weg zu sein (Glide z.B.).

Und heute ist FP16 der große Burner und LL wie Glide ebenfalls ;D

Das beste Beispiel ist FP16. Man braucht nicht unbedingt viel FP32 Leistung, vieles deutet drauf hin das FP16 völlig ausreicht. Da FP16 um einiges kleiner ist auf dem CHIP als FP32 könnte man viel mehr Recheneinheiten verbauen und so viel mehr Leistung mit dem CHIP erzielen. Nur will das keiner weil dann verliert man ja seine Alleinstellungsmerkmale.
Das klang vor >10 Jahren noch ganz anders:
https://alt.3dcenter.org/artikel/2004/11-29_a.php

Und noch mal nur weil jede CPU nun Async Compute, Tesselation etc mit gewissen Instructionen beherschen muss, heißt das noch lange nicht das Nvidia nicht eine besser Async Compute Einheit bauen kann als AMD.
Es gibt keine "Async Compute Einheit" :rolleyes:

Also ich lese hier Tess Faktor Bereich [2..64] Wobei 64 der HÖCHSTFAKTOR ist.
Wenn die DX11-Spezifikation einen Tesselleationfaktor von bis zu 64 vorschreibt, dann muss die Hardware natürlich mindestens diesen Faktor 64 unterstützen.

Sie könnte auch 128 unterstützen und wäre noch DX11-konform, mit Faktor 32 aber nicht mehr.

Dann sollte AMD schnellstens lernen wie wichtig Forenarbeit und virales Marketing für den Umsatz/Marktanteil ist.
Für schlappe 300€ pro Woche könnte ich da echt was tun für die. Break-even ist bei nicht mal 50 zusätzlich verkauften Karten im Monat.
Warum sollte AMD dafür bezahlen, wenn ihr es umsonst macht? ;D

[Digidi]

Es gibt keine "Async Compute Einheit" :rolleyes:




Bei AMD schon.

https://en.wikipedia.org/wiki/Graphics_Core_Next


The Asynchronous Compute Engine (ACE) is a distinct functional block serving computing purposes. It purpose is similar to that of the Graphics Command Processor.

[Bucklew]

Bei AMD schon.
Schreib dann nächstes Mal "Engine" und nicht "Einheit", dann ist es eindeutig. Einheit klingt nach einer Shadereinheit, aber nicht nach der ACE, die ja ein Sheduler ist.

[Digidi]

Schreib dann nächstes Mal "Engine" und nicht "Einheit", dann ist es eindeutig. Einheit klingt nach einer Shadereinheit, aber nicht nach der ACE, die ja ein Sheduler ist.
Wieso soll ich das Wort Engine Schreiben. Das Deutsche Wort heist nun mal Einheit :rolleyes:

Denn eine Einheit ist ein:"functional block"

[Bucklew]

Wieso soll ich das Wort Engine Schreiben. Das Deutsche Wort heist nun mal Einheit :rolleyes:
Aha. Das Deutsche Wort für Engine ist also Einheit...

https://www.dict.cc/englisch-deutsch/unit.html
unit
Einheit {f} [Maßeinheit etc.] [auch mil.]

Ich dachte schon NVIDIA soll irgendwelche Shaderunits entwickeln, die Async beherrschen ;D Dabei ist das einfach nur eine Sache der Steuerungslogik, so wie die ACE bei GCN ebenfalls nur Teil der Steuerlogik ist.

[Digidi]

Aha. Das Deutsche Wort für Engine ist also Einheit...

https://www.dict.cc/englisch-deutsch/unit.html


Ich dachte schon NVIDIA soll irgendwelche Shaderunits entwickeln, die Async beherrschen ;D Dabei ist das einfach nur eine Sache der Steuerungslogik, so wie die ACE bei GCN ebenfalls nur Teil der Steuerlogik ist.

Ja in diesem Sinne schon.
Hier in den Artikeln ist auch nur von Einheiten die Reden. Es sind Funktionseinheiten und jeder Mensch in der Branche in Deutschland redet von FunktionsEinheiten

https://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/34753-asynchronous-shader-sollen-amd-grafikkarten-weiter-beschleunigen.html
https://www.computerbase.de/2013-10/amd-radeon-r7-260x-r9-270x-und-280x-test/2/
https://www.3dcenter.org/artikel/die-fehlenden-asynchronous-shader-bei-nvidia

Ich würde dir mal empfehlen dich vorher besser zu Informiren und vergiss dict.cc das ist hauptsächlich das allgemeingültige Englisch das kannst du hier nicht gebrauchen. Shader Engine übersetzt man auch nicht Shader Motor!

Und nein so einfach ist das nicht. Normalerweise weist der Command Prozessor den Shadern die Aufgaben zu, dies kann er aber nur begrenzt. Wenn dann Shader nicht ausgelastet ist brauchst du eine Weitere Einheit die dies Erkennt und Ihn mit weiteren Aufgaben füttert. Das ist hoch komplex denn man kann nicht einfach so mal was in die Shader schmeißen

:facepalm:

[Bucklew]

Ja in diesem Sinne schon.
Hier in den Artikeln ist auch nur von Einheiten die Reden. Es sind Funktionseinheiten und jeder Mensch in der Branche in Deutschland redet von FunktionsEinheiten
Offensichtlich sinnlos mit dir zu diskutieren. Man liefert dir sogar noch Belege für deine falsche Übersetzung und du nimmst dir lieber die Zeit andere Leute zu suchen, die es genauso falsch machen, als einfach mal anzunehmen, dass der Begriff falsch gewählt ist. Und dann noch ein Facepalm hinterher. Passt aber, denn deine Aktion ist definitiv Facepalm :rolleyes:

Selbst deine Links belegen, dass der Begriff falsch ist. Es ist entweder von "Einheit" die Rede (durchaus in Ordnung) oder von ACE-Einheit (also Engine-Einheit). Auch in Ordnung. Von einer "Async Compute Einheit" ist nirgends die Rede.

[Digidi]

Offensichtlich sinnlos mit dir zu diskutieren. Man liefert dir sogar noch Belege für deine falsche Übersetzung und du nimmst dir lieber die Zeit andere Leute zu suchen, die es genauso falsch machen, als einfach mal anzunehmen, dass der Begriff falsch gewählt ist. Und dann noch ein Facepalm hinterher. Passt aber, denn deine Aktion ist definitiv Facepalm :rolleyes:
Weist du was du bist ein Troll ich hab dir jetzt 3 Links gepostet wo die ACE "EINHEITEN" Sind. Geht wohl nicht in deinen Kopf hinein das es auch noch abseitz vom Wörterbuch eine Technische Sprache gibt die noch nicht festgehalten ist weil es zu neu ist. Aber ich merke schon mit wem es hier eher Sinnlos ist zu diskutieren. Das sind übrigens Journalisten die die Texte Schreiben die sollten der deutschen Sprache mächtig sein.

:facepalm:

Du blamierst dich Gerade!

Und nur mal so bei Shader Engines! redet man auch von Shader Einheiten und nicht Shader Motoren!

https://books.google.de/books?id=LmatCwAAQBAJ&pg=PA22&dq=shader+einheiten&hl=de&sa=X&ved=0ahUKEwin7oG2jPrVAhUCOxoKHYK8D_AQ6AEILjAB#v=onepage&q=shader%20einheiten&f=false

[Bucklew]

Du blamierst dich Gerade!
Nein, du schaust gerade in den Spiegel, auch wenn du dein Facepalm postest.

Ignoreliste, wer fehlende Argumente durch Beleidigungen ersetzt, mit dem ist eine Diskussion sinnlos.

[Digidi]

Nein, du schaust gerade in den Spiegel, auch wenn du dein Facepalm postest.

Ignoreliste, wer fehlende Argumente durch Beleidigungen ersetzt, mit dem ist eine Diskussion sinnlos.

Wo sind denn deine Beweise? Selbst in Büchern ist von Einheiten die Rede. Das du das nicht zugeben kannst ist armselig.

Und um die noch einen Beweis zu liefern. Die Game Engine(unity, source etc...) ist auf deutsch weil man kein Wort so richtig gefunden hat eine Spiele- Engine. Grob wird es laut Wikipedia mit Spielwerk übersetzt.

https://de.m.wikipedia.org/wiki/Spiel-Engine

Sprache ist übrigens ein fortschreitender Prozess!

Und um dir noch einen Hinweis zu geben schau im Oxford English an welche Definition Engine hat und wo es her kommt.

https://en.oxforddictionaries.com/definition/engine

[scully1234]

Es will ja auch keiner sagen, dass jetzt jeder Indie-Hersteller auf DX12/Vulkan setzen soll.
Aber Spieleschmieden, die großes wollen, müssen die bittere Pille aus meiner Sicht halt schlucken .

Wieso müssen sie das?

Solange noch ein DX11 Renderpfad existiert ,indem zu mindestens ein IHV noch Manpower und Ressourcen versenkt, der 70% des dedizierten Marktes inne hat,ist die Sachlage eigentlich klar

Zudem zeigt sich zusehends das die "bittere Pille" selbst für große Studios, zu groß ist ,um noch wirtschaftlich sinnvoll zu operieren ,gegen Mitbewerber die sich mit DX11 ins "gemachte Nest" setzen können

Genau daran wird DX12 und anderer low Level Ansätze nämlich scheitern, wenn sich die Einsicht durchsetzt, das man mit DX11 zwar nicht top of the Hill ist beim hardwarenahen Zugriff, aber wirtschaftlich gesehen mit weniger studiointernen Manpower, und ebenso ans Ziel kommt für beide IHVs

Für AMD kommt LL nur gelegen,weil man Arbeit delegieren kann in Richtung Spieleschmiede, Arbeit die eben auch richtig ins Budget geht

Was aber passiert wenn Nvidia mit 70% Marktdurchdringung, ihren gut funktionierenden Dx11 Treibersupport aufrecht erhält ,ist abzusehen wo sich das einpendeln wird

[gravitationsfeld]

Das Problem in eurer Argumentation ist, dass ihr alle meint DX11 waere performant genug bisher. Ist es nicht. Jede Engine seit Jahren geht etliche Kompromisse ein um den CPU-Overhead niedrig genug zu halten.

Es sind Titel in entwicklung, die schlichtweg einfach nicht moeglich gewesen waeren mit den alten APIs.

[scully1234]

Es sind Titel in entwicklung, die schlichtweg einfach nicht moeglich gewesen waeren mit den alten APIs.

Was nützt dir das denn ,wenn die Spieleschmieden sich das wirtschaftlich nicht leisten können, auf mehreren Hochzeiten zu tanzen?

Und DX11 ist auch noch keine Sackgasse was die Entwicklung betrifft, ebenso wie Hardware bei der Rohpower und Featureset noch weitere Möglichkeiten eröffnet,selbst bei diesem alten Renderpfad

Der wirtschaftliche Aspekt ist nun mal nicht unbedeutend, selbst nicht für so Größen wie DICE und Epic, was da teilweiße auf DX12 und Vulcan gebacken wurde, wäre ohne Unterstützung gewisser Kreise doch so auch nie verwirklicht worden

[iuno]

Das Problem in eurer Argumentation ist, dass ihr alle meint DX11 waere performant genug bisher. Ist es nicht.
Ist zugegebenermassen auch leicht zu glauben, wenn ein Umbau bisher im Bestfall bei einem Hersteller etwas bringt und teils auch noch deutlich schlechter laeuft.
Fuer mich kommt es auch etwas wie ein Checklistenfeature rueber. Bei MS mag das ja noch Sinn machen, aber sonst doch nicht. Wieso baut man einen Titel auf eine neue API um, wo es ueberhaupt nichts bringt oder hinterher gar schlechter laeuft und bringt das so auf den Markt?

Was nützt dir das denn ,wenn die Spieleschmieden sich das wirtschaftlich nicht leisten können, auf mehreren Hochzeiten zu tanzen?
Wer zwingt sie denn dazu? Vulkan und gut.

[scully1234]

Wer zwingt sie denn dazu? Vulkan und gut.

Und die Arbeit erledigt sich von allein?

Bei DX11 unterstützen zumindestens noch beide bzw müssen das sogar , bei Vulcan stehen die Spieleschmieden wenns schlecht läuft, völlig auf sich alleine gelassen da, ist es nicht gerade das Prestigeobjekt eines gewissen IHV

Freilich freuen sich da beide Hersteller, schließlich wird ihnen ja Last abgenommen, und der Gamer kann dann nur noch auf die Spieleschmiede schimpfen, wenn sie den Vulcan/DX12 Pfad versemmeln

[iuno]

;D nice try

[aufkrawall]

bei Vulcan stehen die Spieleschmieden wenns schlecht läuft, völlig auf sich alleine da, ist es nicht gerade das Prestigeobjekt eines gewissen IHV

Behauptest du jetzt einfach mal so.

[scully1234]

Behauptest du jetzt einfach mal so.

Nicht nur behaupten, das war sogar das Ziel der LL Api , mehr Verantwortung oder nenne es "Kontrolle"in die Hände von Epic,DICE und Co zu legen...

Nur diese Kontrolle kostet eben auch mehr Budget auf der anderen Seite der Medallie

Und ob sich das wirklich alle antun werden, allen voran die kleineren Indie Entwickler , steht auf wackeligen Füßen

[Bucklew]

Das Problem in eurer Argumentation ist, dass ihr alle meint DX11 waere performant genug bisher. Ist es nicht. Jede Engine seit Jahren geht etliche Kompromisse ein um den CPU-Overhead niedrig genug zu halten.
Nur leider ist das gar nicht unsere Argumentation.

[Troyan]

Lawbreakers sieht besser aus als Doom und läuft mit DX11 fantastisch und ohne CPU-Limit im Gegensatz zum kaputten OpenGL Pfad.

DX11 auf nVidia-Hardware läuft fantastisch für eine 8 Jahre alte API. Solange man nicht wirklich künstlich die Draw-Call-Anzahl in die Höhe schießen lässt (siehe Ashes oder Rise of the Tomb Raider), sind selbst 5 Jahre alte Prozessoren wie mein i7-3770 vollkommen ausreichend.

[Digidi]

Nur leider ist das gar nicht unsere Argumentation.

Deine Argumentation kennt man ja :rolleyes:

[Kartenlehrling]

Und DX11 ist auch noch keine Sackgasse was die Entwicklung betrifft,
ebenso wie Hardware bei der Rohpower und Featureset noch weitere Möglichkeiten eröffnet, selbst bei diesem alten Renderpfad



Am Beispiel von PhysX kann man sehr schön sehen, das die Grafikkarten zu schnell geworden sind das api und featurs sehr wohl ausbremsen können.
Das Nvidia es lieber wär das wir noch 5-6 Jahre DX11 Spiele rumgurken, glaub ich gern, sie kommen schliesslich damit immer noch besser zurecht.

http://www.pcgameshardware.de/Mafia-2-Spiel-13147/Specials/Vorbereitung-Mafia-3-Benchmarks-1166573/#a3
Mafia 2 optisch aufgewertet - Benchmarks mit PhysX

[gravitationsfeld]

Was nützt dir das denn ,wenn die Spieleschmieden sich das wirtschaftlich nicht leisten können, auf mehreren Hochzeiten zu tanzen?

Und DX11 ist auch noch keine Sackgasse was die Entwicklung betrifft, ebenso wie Hardware bei der Rohpower und Featureset noch weitere Möglichkeiten eröffnet,selbst bei diesem alten Renderpfad

Der wirtschaftliche Aspekt ist nun mal nicht unbedeutend, selbst nicht für so Größen wie DICE und Epic, was da teilweiße auf DX12 und Vulcan gebacken wurde, wäre ohne Unterstützung gewisser Kreise doch so auch nie verwirklicht worden
Der Grossteil der Kosten sind Assets, nicht Code.

[TGKlaus]

Lawbreakers sieht besser aus als Doom und läuft mit DX11 fantastisch

Große Teiler der Level sehen einfach nach Poligonarmut aus, die mit Bonbonfarben wohl übertüncht werden soll.

[scully1234]

Das Nvidia es lieber wär das wir noch 5-6 Jahre DX11 Spiele rumgurken, glaub ich gern, sie kommen schliesslich damit immer noch besser zurecht.


Bisher hat auch noch keiner der Vulcan und DX12 Beführworter , einen Präzedenzfall geschaffen, um dieses Vorgehen ad absurdum zu führen, neben wie gesagt den wirtschaftlichen Aspekt

Sowohl ist es mit DX11 möglich moderne Games zu erstellen, als auch seine Kosten im Augen zu behalten als Spieleschmiede


Es spricht also zum gegenwärtigen Zeitpunkt nicht wirklich viel für LL, wenn man diese Gegebenheiten mit einbezieht

Und mit neuen Prozessoren ,und zunehmenden 6 bzw 8 Core Support ,verringert sich der Bedarf danach nochmals.

Den Weg breitbandiger zu aggieren hat AMD,und Intel ja nun auch geschaffen,mit der 6/8Kern Ära im Budget Segment,als auch im Konsolensektor

[aufkrawall]

Lawbreakers sieht besser aus als Doom und läuft mit DX11 fantastisch und ohne CPU-Limit im Gegensatz zum kaputten OpenGL Pfad.

Doom ist mit OGL recht genügsam bei der CPU (dildos Schrott-Bulldozer zählt nicht). Dass es mit UE4 und DX11 im CPU-Limit schneller liefe, möchte ich mal arg bezweifeln.

[pixeljetstream]

Glaub man redet hier gegen ne Wand wenn man behauptet dass dx12/vulkan so low-level auch nicht sind. Ich war hier nicht im Forum als dx10 kam, war es da genauso? Im Prinzip interessierte die Zwischengeneration mit dx10 doch auch nicht so sehr. Der größere Hardwaresprung war doch mit dx11 erst, obwohl die API Grundsteine mit 10 gelegt wurden.
In N Jahren wenn dx/vk?? kommt und die nächste größere Änderung einführen wird garantiert ??-1 genauso hart verteidigt werden, von Leuten die weder das eine noch das andere wirklich selber benutzt haben ;)
Die neuen APIs sind immer noch sehr jung, die großen Engines werden auch mal nicht eben so umgeschrieben von ihrem grunsätzlichen Design. Das kommt aber zwangsläufig irgendwann, war doch vorher genauso.

Ich denke auch dass mehr Verantwortung "teurer" kommt, aber das allein macht ja nicht die neue API aus und es ist ja immer offen wer die Verantwortung trägt. Man darf nicht unterschätzen, dass die Optimierungen rund um dx11 auch Geld gekostet haben, oder die ganzen Tricks um overhead zu sparen in diesen Apis auch nicht optimal wartbar sind wie gravitationsfeld sagt.
Wir sehen das halt jetzt in der Umbruchsphase nicht so direkt, weil ja schon zig Jahre in das alte reingeflossen sind. Das erinnert mich an die Evolutionsleugner, den Berg ausgestorbener Arten/Permutationen bis zum jetzigen Design sieht man halt nicht so vor Augen.

Es gibt ein breites Spektrum an Entwicklern, und es gibt ein sehr breites Spektrum an Middleware. Jeder findet schon was passendes. Die großen Publisher konsolidieren doch eh schon ihre Renderingteams und Forschungsabteilungen. Der Indieentwickler greift doch eh meist zu Unreal, Unity & Co weil dann auch die ganze Toolpipeline bekommt. Und selbst wenn ich nun selbst mein Indie game in Vulkan schreib, mach ich halt das game so dass es in N GB passt und vereinfach mir so das Memorymanagement ;)
Erst wenn man bleeding edge sein will, skalieren, wirds komplizierter, aber dann ist die Sache auch offensichtlich wichtig genug und man investiert darin, oder nutzt eben die Technik anderer.

Darum gibt es in der Entwicklerszene auch nicht den Aufschrei, man steigt halt um wann es sinnvoll ist. Aber man hat das ja vorher auch die Jahre getan. Die meisten Renderingentwickler freuen sich doch über neues Spielzeug. Klar gibt's Sektoren wo OpenGL1 noch läuft, aber da ist die Erwartungshaltung jetzt auch nicht so hoch ;)

Irgendwen bezahlt man immer, ob's die eigenen Leute sind, die Lizenzgebühren oder die Hardware. Toptechnik kostet, und Unabhängigkeit auch. Aber im Prinzip ist die Branche doch super weit gekommen, dass wir mit den relativ günstigen Engines schon so viel Technik zur Verfügung haben.

[fondness]

Glaub man redet hier gegen ne Wand wenn man behauptet dass dx12/vulkan so low-level auch nicht sind. Ich war hier nicht im Forum als dx10 kam, war es da genauso? Im Prinzip interessierte die Zwischengeneration mit dx10 doch auch nicht so sehr. Der größere Hardwaresprung war doch mit dx11 erst, obwohl die API Grundsteine mit 10 gelegt wurden.
In N Jahren wenn dx/vk?? kommt und die nächste größere Änderung einführen wird garantiert ??-1 genauso hart verteidigt werden, von Leuten die weder das eine noch das andere wirklich selber benutzt haben ;)
Die neuen APIs sind immer noch sehr jung, die großen Engines werden auch mal nicht eben so umgeschrieben von ihrem grunsätzlichen Design. Das kommt aber zwangsläufig irgendwann, war doch vorher genauso.


Der einzige Grund, warum bestimmt User hier so gegen DX12/Vulkan argumentieren ist doch offensichtlich: Weil es von AMD gepusht wurde bzw. sich manche NV-User warum auch immer benachteiligt fühlen.

[AffenJack]

Ist zugegebenermassen auch leicht zu glauben, wenn ein Umbau bisher im Bestfall bei einem Hersteller etwas bringt und teils auch noch deutlich schlechter laeuft.
Fuer mich kommt es auch etwas wie ein Checklistenfeature rueber. Bei MS mag das ja noch Sinn machen, aber sonst doch nicht. Wieso baut man einen Titel auf eine neue API um, wo es ueberhaupt nichts bringt oder hinterher gar schlechter laeuft und bringt das so auf den Markt?


Viel mehr ist es gerade in meinen Augen auch nicht, aber Gravitationsfeld hat einen sehr wichtigen Punkt angesprochen. Du kannst damit Sachen machen, die vorher nicht gingen. Das wirst du aber erst sehen, wenn du richtige DX12 only Games hast. Bisher gibts da aber noch keins (Windows DRM Kram zählt nicht). Das ganze Mischzeug kann man vergessen.

[scully1234]

Ich denke auch dass mehr Verantwortung "teurer" kommt, aber das allein macht ja nicht die neue API aus und es ist ja immer offen wer die Verantwortung trägt.

Dieses teurer ist in einer funktionierenden Marktwirtschaft aber ein genereller Faktor, es sagt ja auch keiner das DX12/Vulcan per se schlechter ist

Nur wird kein Kunde den neuen Renderpfad akzeptieren, solange es dort keine verwertbaren Vorteile gibt, die er sehen/spielen kann, bzw ihn sich mit Teils schlechterem Resultat assimilieren, der Beispiele gibts ja derzeit auch noch genügend.

Wenn man es irgendwie schafft die IHVs weiterhin im selben Umfang mitwirken zu lassen, kann das was werden, schafft man das nicht, wird der "teurer" Faktor für einige zur Crux

"Unabhängiger" muss nicht zwangsweise zu besseren Resultaten führen, und da besteht schon ein gewisses Risiko, das es aus dem Ruder läuft, wenn die Kostenkalkulation sich einseitig verschiebt in Richtung Spieleschmiede

[Grendizer]

Viel mehr ist es gerade in meinen Augen auch nicht, aber Gravitationsfeld hat einen sehr wichtigen Punkt angesprochen. Du kannst damit Sachen machen, die vorher nicht gingen. Das wirst du aber erst sehen, wenn du richtige DX12 only Games hast. Bisher gibts da aber noch keins (Windows DRM Kram zählt nicht). Das ganze Mischzeug kann man vergessen.


Ich weiss nicht. Momentan dient DX12 primär dazu AMD Karten auf ein Niveau das teilweise besser oder vergleichbar zu nVidia Karten ist zu bringen. Es wird ja nicht auf einmal massig GPU und CPU Ressourcen frei, sondern ist gibt eine Steigerung der fps in 15-20% Bereich. Das reicht meiner Meinung nach nicht für wahrnehmbar gesteigerte Effekte.

Ich glaube auch nicht, das nVidia mit Volta den Scheduler so massiv umbauen kann, das er mit AC besser harmoniert. Mit Sicherheit werden die Bestrebungen in die Richtung gehen, da besser zu werden, aber mal schauen in welchem Umfang.

[pixeljetstream]

Nur wird kein Kunde den neuen Renderpfad akzeptieren, solange es dort keine verwertbaren Vorteile gibt, die er sehen/spielen kann, bzw ihn sich mit Teils schlechterem Resultat assimilieren, der Beispiele gibts ja derzeit auch noch genügend.

Da gebe ich Dir Recht, aber wir sind eben noch in der "Mischzeug" Phase. Bei den engines mit dx9 und dx10 Pfaden war es doch ähnlich? Erst die "dx11 only" Titel waren dann "anders". Das praktische dx11/dx12 zu shippen ist ja dass man Erfahrung sammelt, was geht, was nicht... selbiges bei den Herstellern, wie sehen die Anwendungsstreams aus, was machen die Leute. Was sollten die Entwickler, was der Treiber, was die Hardware anders machen. Das normale Prozedere.

[Bucklew]

Der einzige Grund, warum bestimmt User hier so gegen DX12/Vulkan argumentieren ist doch offensichtlich: Weil es von AMD gepusht wurde bzw. sich manche NV-User warum auch immer benachteiligt fühlen.
Chapeau, aus einer technischen sehr schwierigen und vielfarbigen Situation einen einfachen Fanboy-Krieg zu machen ;D

Und das mit dem AMD-Logo als Avatar :facepalm:

[VooDoo7mx]

Ich glaube auch nicht, das nVidia mit Volta den Scheduler so massiv umbauen kann, das er mit AC besser harmoniert. Mit Sicherheit werden die Bestrebungen in die Richtung gehen, da besser zu werden, aber mal schauen in welchem Umfang.
Tja und das ist eben der Unterschied zwischen AMD und nVidia. nVidia baut nicht seine Architektur nicht um einen Teilaspekt zu verbessern, sondern um überall besser zu sein. Wenn da ein neuer Chip mit 40% mehr Rechenleistung kommt, Dann kommen die 40% überall an. egal ob Direct X11, 12, Open GL oder Vulkan.

Außerdem profitiert auch Pascal von Async Compute, nur eben weniger als bei AMD. Was einfach daran liegt, dass bei nVidia schon die Auslastung der Recheneinheiten fast am Optimum ist. Bei AMD braucht man solche Features mehr, da die Chips eigentlich so gut wie nie, ihre Leistung auf die Straße bringen können.

Und die Direct X12/Vulkan "Stärke" von AMD, worauf die Fanboys gerne drauf rumreiten, ist im Endeffekt auch nur ein Mythos.
AMD hat nur tatsächlich einen Vorteil wenn der entsprechende Pfad durch AMD Zuwendungen gesponsert wurde. Es gibt reihenweise DX12oder Vulkan Spiele wo es keinen deutlichen Vorteil für AMD gibt oder auch AMD Karten an Geschwindigkeit verlieren oder sogar die Geschwindigkeit immer noch gleichwertig oder sogar hinter vergleichbaren nVidia Karten ist.
Was im Endeffekt nervt, sind das die Fanboys immer nur auf den gleichen 4-5 gesponserten Spielen rumreiten, den Rest aber wo es auch mit DX12/Vulkan nicht sehr rosig aussieht für AMD einfach ignorieren. Und gerade an diesen Beispielen sieht man auch das Vulkan / Direct X12 kein Heilmittel für alles ist.
Die Fanboys sind ja praktisch der Meinung, der Entwickler müsse nur den magischen DirectX12 oder Vulkan Knopf drücken und schon ziehen AMD Karten wie von Zauberhand an nVidia Karten vorbei. Jetzt zwar nicht aber in 3 Jahren... ganz sicher... vielleicht...

Und dann kommt natürlich auch noch die böse Gameworks Verschwörung die AMD Karten künstlich zurück hält. Das selbst wenn man alle Gameworks Effekte abstellt, AMD Karten trotzdem hinten liegen ist natürlich komplett unwichtig. Weil... Weil äääh... GAMEWORKS!

[Troyan]

Da gebe ich Dir Recht, aber wir sind eben noch in der "Mischzeug" Phase. Bei den engines mit dx9 und dx10 Pfaden war es doch ähnlich? Erst die "dx11 only" Titel waren dann "anders". Das praktische dx11/dx12 zu shippen ist ja dass man Erfahrung sammelt, was geht, was nicht... selbiges bei den Herstellern, wie sehen die Anwendungsstreams aus, was machen die Leute. Was sollten die Entwickler, was der Treiber, was die Hardware anders machen. Das normale Prozedere.

Wir befinden uns zwei Jahre nach dem offiziellen Release von DX12 und die Ergebnisse bis heute sind milde ausgedrückt X-(

Der DX11 Patch von Crysis 2 kam zwei Jahre nach dem Release von DX11 auf den Markt und er hat die BQ massiv gesteigert und eindrucksvoll gezeigt, was alles möglich ist.

Bis jetzt ist DX12 ein Flop. Aber vielleicht schafft es DX13 wieder das Ruder herumzuwerfen und eine vernünftige Lösung für das Problem zu finden. :biggrin:

[gravitationsfeld]

Tja und das ist eben der Unterschied zwischen AMD und nVidia. nVidia baut nicht seine Architektur nicht um einen Teilaspekt zu verbessern, sondern um überall besser zu sein. Wenn da ein neuer Chip mit 40% mehr Rechenleistung kommt, Dann kommen die 40% überall an. egal ob Direct X11, 12, Open GL oder Vulkan.

Außerdem profitiert auch Pascal von Async Compute, nur eben weniger als bei AMD. Was einfach daran liegt, dass bei nVidia schon die Auslastung der Recheneinheiten fast am Optimum ist. Bei AMD braucht man solche Features mehr, da die Chips eigentlich so gut wie nie, ihre Leistung auf die Straße bringen können.

Und die Direct X12/Vulkan "Stärke" von AMD, worauf die Fanboys gerne drauf rumreiten, ist im Endeffekt auch nur ein Mythos.
AMD hat nur tatsächlich einen Vorteil wenn der entsprechende Pfad durch AMD Zuwendungen gesponsert wurde. Es gibt reihenweise DX12oder Vulkan Spiele wo es keinen deutlichen Vorteil für AMD gibt oder auch AMD Karten an Geschwindigkeit verlieren oder sogar die Geschwindigkeit immer noch gleichwertig oder sogar hinter vergleichbaren nVidia Karten ist.
Was im Endeffekt nervt, sind das die Fanboys immer nur auf den gleichen 4-5 gesponserten Spielen rumreiten, den Rest aber wo es auch mit DX12/Vulkan nicht sehr rosig aussieht für AMD einfach ignorieren. Und gerade an diesen Beispielen sieht man auch das Vulkan / Direct X12 kein Heilmittel für alles ist.
Die Fanboys sind ja praktisch der Meinung, der Entwickler müsse nur den magischen DirectX12 oder Vulkan Knopf drücken und schon ziehen AMD Karten wie von Zauberhand an nVidia Karten vorbei. Jetzt zwar nicht aber in 3 Jahren... ganz sicher... vielleicht...

Und dann kommt natürlich auch noch die böse Gameworks Verschwörung die AMD Karten künstlich zurück hält. Das selbst wenn man alle Gameworks Effekte abstellt, AMD Karten trotzdem hinten liegen ist natürlich komplett unwichtig. Weil... Weil äääh... GAMEWORKS!
Ich wiederhole mich, aber auch bei NVIDIA wuerde asynchronous compute etwas bringen. Das ein einziger Kernel alle Ports der SMs auslastet ist extrem unwahrscheinlich. Entweder ist man ALU- Tex- oder Bandbreiten-limitiert. Ich hab es selten erlebt das etwas komplett ausbalanciert ist.

Und auch abgesehen davon ist die volle Auslastung ein Mythos. Jede Applikation hat Read-after-Write-Barriers zwischen Render-Schritten und da kann auch NVIDIA nichts anderes machen als die Kernel-Pipeline komplett zu flushen. Das fuehrt immer zu Bubbles. Die koennte man mit Compute-Kerneln von einer zweiten Queue auffuellen.

Dazu kommt dass NVIDIA meiner Kenntnis nach ueberhaupt keine Moeglichkeit hat Grafik- und Compute-Kernel gleichzeitig laufen zu lassen. Nicht einmal von der gleichen Queue. Entweder ist der ganze Chip im Grafik-Modus oder im Compute-Modus. Wechsel dazwischen sind also auch immer mit Bubbles verbunden. pixeljetstream kann mich da aber gerne korrigieren.

[unl34shed]

Dazu kommt dass NVIDIA meiner Kenntnis nach ueberhaupt keine Moeglichkeit hat Grafik- und Compute-Kernel gleichzeitig laufen zu lassen. Nicht einmal von der gleichen Queue. Entweder ist der ganze Chip im Grafik-Modus oder im Compute-Modus. Wechsel dazwischen sind also auch immer mit Bubbles verbunden. pixeljetstream kann mich da aber gerne korrigieren.

Stimmt nicht ganz, seit Kepler oder Maxwell können sie parallel Grafik und Compute ausführen, aber im Vergleich zu AMD nur recht grob auf dem Chip verteilen. Bei Maxwell kam noch hinzu, dass jeder Content Switch einen Pipeline flush benötigte (--> daher der Leistungsverlust bei Async Compute) dies ist mit Pascal nicht mehr nötig, die grobe Aufteilung der Tasks bleibt aber (waren glaub 1/8 Schritte). So genau bring ich es nicht mehr zusammen.

Kam aber damals raus, als Maxwell wegen der Async Compute schwäche kritisiert wurde, die man ja laut Nvidia mit einem Treiber lösen wird. Oh wunder gekommen ist nichts.



Und bzgl der DX12 Spiele, die nicht bringen, sind das nicht DX12_FL11 Spiele, also auch nur DX11 in neuem Gewand, die das nur als Checklisten Feature bekommen haben?

[Grendizer]

Und bzgl der DX12 Spiele, die nicht bringen, sind das nicht DX12_FL11 Spiele, also auch nur DX11 in neuem Gewand, die das nur als Checklisten Feature bekommen haben?


Ja.... aber DX12 bedeutet halt automatisch nur noch Windows 10. Damit reduzieren die Spielehersteller den potentiellen Markt schon gravierend.

[Fragman]

Ja.... aber DX12 bedeutet halt automatisch nur noch Windows 10. Damit reduzieren die Spielehersteller den potentiellen Markt schon gravierend.

jup, deshalb interessiert mich dx12 als win7und win8.1 nutzer ueberhaupt nicht.

[AffenJack]

Dazu kommt dass NVIDIA meiner Kenntnis nach ueberhaupt keine Moeglichkeit hat Grafik- und Compute-Kernel gleichzeitig laufen zu lassen. Nicht einmal von der gleichen Queue. Entweder ist der ganze Chip im Grafik-Modus oder im Compute-Modus. Wechsel dazwischen sind also auch immer mit Bubbles verbunden. pixeljetstream kann mich da aber gerne korrigieren.

Bei Kepler oder Maxwell vielleicht, aber bei Pascal sieht mir das anders aus

https://cdn01.hardwareluxx.de/razuna/assets/1/B1D70B7B73314F2DB3D169B757FFA77D/img/570480B923DF46F790450C10AD23401B/GDC_Editors_Day_2017_1488327197_-_unmarked_Pagina_040_570480B923DF46F790450C10AD23401B.jpg
https://cdn01.hardwareluxx.de/razuna/assets/1/B1D70B7B73314F2DB3D169B757FFA77D/img/D2E18BEF88634A7FBB366C3C90BC3B70/GDC_Editors_Day_2017_1488327197_-_unmarked_Pagina_044_D2E18BEF88634A7FBB366C3C90BC3B70.jpg
https://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/42126-nvidia-auf-der-gdc-dx12-gameworks-findet-den-weg-zu-directx-12.html

Oder die ganze GDC Präsentation dazu:
http://www.gdcvault.com/play/1024344/

Das ganze zeigt doch, dass Nv mit Pascal Async kann, sonst würde man nicht die doppelte geschwindigkeit bei der Partikelberechnung mit Async kriegen. AMDs Lösung ist besser und ich weiß nicht ob man Nvs Async außerhalb von Physik sinnvoll verwenden kann, aber da ists auf jeden Fall.

[pixeljetstream]

Der DX11 Patch von Crysis 2 kam zwei Jahre nach dem Release von DX11 auf den Markt und er hat die BQ massiv gesteigert und eindrucksvoll gezeigt, was alles möglich ist.

dx10 brachte die primären API Änderungen 2 Jahre vor dx11, also haben wir quasi 4 Jahre, nach der Rechnung bis die API "fruchtete".

Auch wenn man mit dem Jetztzustand über alle Titel hinweg unzufrieden ist, so ändert das imo nichts daran dass derartige API Änderungen von Zeit zu Zeit notwendig sind. Natürlich hat AMD hier nicht uneigennützig gehandelt mit seinem Push von Mantle usw. aber so funktioniert das Spiel eben.

Jeder versucht den Markt mit seinen Stärken zu gewinnen, nicht jeder Zug ist erfolgreich. Das heißt nicht automatisch das alles Aspekte der Technik schlecht sind/waren usw.

Wie gravitationsfeld sagt, async compute hat seine Daseinsberechtigung. Natürlich wird man nicht mehr diese krassen Zuwächse wie bei den alten GCNs sehen, auch AMD arbeitete ja daran mehr Auslastung hinzubekommen.
Man investiert da wo es weh tut, wie vorher schon paar mal erwähnt, sie investieren in Grafik weil async alleine nicht reicht, und wir investieren in async weil am Ende jedes Prozent gut ist.
http://on-demand.gputechconf.com/gtc/2016/presentation/s6138-christoph-kubisch-pierre-boudier-gpu-driven-rendering.pdf (slide 10 geht auf die Problematik ein, wieviele so interne flushes ausgelöst werden ist sehr architektur spezifisch).
AMD ist ein Risiko eingegangen mit GCN etwas "anderes" zu bauen als klassisches dx11, sie haben damit die Konsolen gewonnen und deren Entwickler glücklich gemacht, mit einer Architektur wo sie sich austoben können. Aber sie konnten eben daraus nicht so sehr jenseits davon profitieren.

NV war hier damals konservativer, die Ironie ist dass das Scheitern bei den Konsolen imo gut dazu beigetragen hat, dass NV noch mehr sich um sein eigenes Schicksal kümmert, PC nun überlebenswichtiger denn je, stark im "Jetzt" sein, mehr Wagnis in andere Märkte (mit Tegra kam Perf/Watt, CUDA/Tesla ewig kaum Gewinn trotz hoher Investitionen in die Infrastruktur) um Wert zu schaffen. Imo eine positive Eigenschaft der Firma ist eben das Scheitern gestärkt zu meistern. Der stärkere Softwarelayer erlaubt hier auf zwei Ebenen selber reagieren zu können. AMD's Strategie ist viel stärker auf die Software außerhalb der Firma angewiesen, das kann klappen (siehe tolle Konsolentitel), aber hat auch sein Risiko und natürlich können sie die Strategie im Rahmen der finanziellen Mittel ändern.

Wenn wir die 4 Jahre von dx10 zu effektivem dx11 nehmen, hat NV noch gut Zeit hier genauso wieder hervorzugehen wie eben nach dx11 auch. Und natürlich kann AMD auch was schaffen. Man brauch nen Schwung Titel um die Treiber zu optimieren, und eben auch Titel die das Zeug eher "nativ" nutzen. Natürlich bin ich biased und sehe NV technologisch und finanziell bestens gerüstet, aber es ist kein Selbstläufer und es ist gut einen (bzw. mehrere) Gegner zu haben der die eigenen Schwächen ausnutzen kann, das gilt ja für alle. Kein Einheitsbrei zu haben, jeder versucht Akzente zu setzen (zumindest technologisch).

Die Entwickler haben eben auch diese Zeit, gibt dann stärkere HW im Markt, mehr win10, mehr Android mit Vulkan, bzw mehr Metal, alle Platformen in Mehrheit auf dem "moderneren" Layer, und damit ist das Investment in diese Technik dann auch wieder sicherer.

Es macht also imo weniger Sinn sich gegenseitig über irgendwelche Features im Detail zu bashen, oder die API Modernisierung als solche in Frage zu stellen. Jeder Techniker wird plausibel für/gegen gewisse Hardwaredetails in den beiden Architekturen argumentieren können. Jeder Softwareentwickler für/gegen gewisse Abstraktionen in den Interfaces. Jede Manager über Kosten der Eigenentwicklung oder Abhängigkeit von Dritten.
aber jetzt kling ich auch wie ne sich wiederholende Schallplatte ;)

[Schnoesel]

Vielen Dank für die erhellenden Erklärungen Pixeljetstream.

Vor allem ist es bezeichnend, dass du der Konkurrenz in Form von AMD mehr Respekt entgegenbringst als es hier der ein oder andere Forist tut. Es gibt eben nicht nur Schwarz und Weiß.

[scully1234]

@pixeljetstream

Also eines muss man deinen Antworten hier ja lassen, sie sind meistens sehr informativ ,sehr oft gespickt mit interessanten Material/Links, und lesen sich in der Summe auch sehr angenehm :up:

[Bucklew]

AMDs Lösung ist besser und ich weiß nicht ob man Nvs Async außerhalb von Physik sinnvoll verwenden kann, aber da ists auf jeden Fall.
Die Lösung ist nicht "besser", sie basiert primär auf ohne Async Compute unausgelasteten Shadereinheiten. Die trotzdem Leistung aufnehmen, wenn man sich mal die Leistungsaufnahme auch von Vega anschaut.

Vor allem ist es bezeichnend, dass du der Konkurrenz in Form von AMD mehr Respekt entgegenbringst als es hier der ein oder andere Forist tut. Es gibt eben nicht nur Schwarz und Weiß.
Der Respekt geht eben schnell verloren, wenn er von deinen Markenkollegen nur wegen seiner Anstellung direkt verunglimpft wird (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11473904#post11473904)

[AffenJack]

Die Lösung ist nicht "besser", sie basiert primär auf ohne Async Compute unausgelasteten Shadereinheiten. Die trotzdem Leistung aufnehmen, wenn man sich mal die Leistungsaufnahme auch von Vega anschaut.


Selbst Nv zeigt, dass sie "Löcher" haben in denen man Async einsetzen kann. Es ist wahrscheinlich weniger als bei AMD, aber eben auch da:

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

[Bucklew]

Selbst Nv zeigt, dass sie "Löcher" haben in denen man Async einsetzen kann. Es ist wahrscheinlich weniger als bei AMD, aber eben auch da:
Nochmal: Ich behaupte nicht, NVIDIA habe gar keine ungenutzten Shader - ich sage, NVIDIA hat deutlich weniger als AMD.

Was AMD "besser" macht ist in Wirklichkeit schlechter: Shadereinheiten verbauen, die keine Gamingleistung bringen, aber elektr. Leistung aufnehmen. AMD ist in Sachen Perf/Watt nicht ohne Grund so weit hinter NVIDIA.

[Kartenlehrling]

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=60984&stc=1&d=1504011957

Wieso profitiert AMD von Codemaster - ASSAO gegenüber von Nvidia - HBAO+,
währenddessen Nvidia kein unterschied zeigt?!!


Neue Grafik-Features und eine gute Kantenglättung

F1 2017 unterstützt HBAO+ aus Nvidias GameWorks-Programm. Gegenüber der im Spiel integrierten Standardvariante (Einstellung „Ein“)
zeigt die aus vielen anderen Titeln bereits bekannte Umgebungsverdeckung eine bessere Erfassung von Objekten. In F1 2017 gibt es allerdings noch eine weitere Alternative.

Das von Codemasters neu entwickelte ASSAO sieht noch einmal besser aus als HBAO+. Manche Schatten wirken zwar etwas „zu dick aufgetragen“,
andere wiederum werden durch HBAO+ aber nicht oder kaum erfasst. Der Redaktion hat ASSAO am Ende besser gefallen.

Interessantes Detail am Rande: Auf einer Grafikkarte von AMD nutzt das UltraHoch-Preset ASSAO als Umgebungsverdeckung.
Auf einem Beschleuniger von Nvidia ist dagegen HBAO+ vorausgewählt.
Bezüglich der Performance macht es sowohl auf einer GeForce GTX 1080 als auch auf einer Radeon RX Vega 64 (Test) kaum einen Unterschied,
welche Umgebungsverdeckung aktiv ist. Damit geht die Empfehlung auch unter diesem Gesichtspunkt weiterhin an ASSAO


https://www.computerbase.de/2017-08/f1-2017-pc-benchmark/

[dildo4u]

Vega könnte im CPU Limit sein man müsste das in 1440p testen.

[Locuza]

Nochmal: Ich behaupte nicht, NVIDIA habe gar keine ungenutzten Shader - ich sage, NVIDIA hat deutlich weniger als AMD.

Was AMD "besser" macht ist in Wirklichkeit schlechter: Shadereinheiten verbauen, die keine Gamingleistung bringen, aber elektr. Leistung aufnehmen. AMD ist in Sachen Perf/Watt nicht ohne Grund so weit hinter NVIDIA.
Die Fähigkeit effektiver Löcher stopfen zu können, kann ziemlich unabhängig von der restlichen Effizienz oder Auslastung der Shader-Units ausfallen.
Oder ist Pascal weniger effizient, als Maxwell, weil er Dynamic Load Balancing implementiert hat?

Das AMD offensichtlich die schlechtere Perf/Watt hat, muss nicht viel mit dem grundlegenden Shader-Design zu tun haben.

[BILD]
Wieso profitiert AMD von Codemaster - ASSAO gegenüber von Nvidia - HBAO+,
währenddessen Nvidia kein unterschied zeigt?!!

https://www.computerbase.de/2017-08/f1-2017-pc-benchmark/
???

In der Teststzene ist HBAO+ auf der Vega praktisch kostenlos, gegenüber der einfachen AO-Lösung, ASSAO kostet dagegen ein paar Prozent.
Bei Nvidia kostet HBAO+ im Vergleich etwas mehr Performance und liegt gleich auf mit ASSAO.
Wirklich seltsam ist, dass das Ultra-Hoch Presetting unterschiedliche Einstellungen für AMD (ASSAO) und Nvidia (HBAO+) trifft.

[Kartenlehrling]

Stimmt.

[fondness]

Die Lösung ist nicht "besser", sie basiert primär auf ohne Async Compute unausgelasteten Shadereinheiten.

Ich zitiere mal Gipsel, weil sonst kommt von dir wieder nur Fanboy-Blabla:

Da bist Du aber kräftig auf dem Holzweg. Deine gezeigte Grafik gilt übrigens nur für Compute bei nV. Traditionell geht gleichzeitiges Ausführen von Shadern aus einem Grafik-Kontext und aus einem Compute-Kontext bei nV nicht. Und zwar GPU-weit. Erst mit Pascal können die SMs einzeln den Kontext switchen (Grafik und Compute auf einem SM mischen geht aber immer noch nicht). Vorher mußte die komplette GPU warten, bis jeder einzelne Thread eines Grafikshaders beendet war, um dann die ganze GPU auf Compute zu schalten. Andersrum genauso. Daher kommen die Performance-Einbrüche bei nV mit vielen Kontext-Switches.
Bei AMD können dagegen beliebige Shader und beliebige Kontexte gleichzeitig laufen. Nicht nur auf der GPU sondern auch in jeder einzelnen CU. Und das schon so lange es GCN gibt. Die einzige Beschränkung für die Ausführung eines Shaders bei AMD ergibt sich durch die verfügbaren Ressourcen (Register, LDS). Im Prinzip könnte eine CU 40 verschiedene Shader aus 40 verschiedenen Kontexten gleichzeitig laufen lassen. Da bietet die Hardware deutlich mehr als bei nV, nämlich maximale Flexibilität. Und dies erlaubt es eben besser als bei nV-GPUs, in bestimmten Abschnitten des Renderns des Bildes brachliegende Ressourcen für anderen Aufgaben zu nutzen. AMD-GPUs benötigen gar keinen Kontext-Switch, da man schlicht beliebige Kontexte simultan abarbeiten kann.

Genau deshalb ist Async-Computer bei AMD "besser", völlig unabhängig von der Auslastung der restlichen Einheiten.

[AffenJack]

Wieso profitiert AMD von Codemaster - ASSAO gegenüber von Nvidia - HBAO+,
währenddessen Nvidia kein unterschied zeigt?!!



Tja, dumm gelaufen, wenn man gegen Gameworks hetzen will, es aber hier schneller auf AMD läuft ;D

[DrFreaK666]

Tja, dumm gelaufen, wenn man gegen Gameworks hetzen will, es aber hier schneller auf AMD läuft ;D

Schau dir die Ergebnisse hier an.
Immer noch dumm gelaufen??
https://youtu.be/HL_WnNO7s-c

[scully1234]

Schau dir die Ergebnisse hier an.
Immer noch dumm gelaufen??
https://youtu.be/HL_WnNO7s-c


Vega (Treiber aus der Hölle)

GTX1070 (gereifter Treiber über mehrere Jahre mit wesentlich mehr Manpower)

Warum wird hier krampfhaft versucht, den Skill in der Programmierung , zu unterminieren ?

AMD hat nunmal nicht die Ressourcen um überall präsent zu sein, das darf man auch mal langsam akzeptieren.

Vor allem immer wieder Gameworks vors Loch zu schieben, ist so langsam nicht mehr zielführend,denn es gibt genügend Beispiele wo sich das völlig konträr verhält

Das ist doch auf der anderen Seite immer der Punkt: "der Treiber reift wie guter Wein bei AMD" da muss man auch nicht meckern ,wenn es irgendwo noch Traubensaft ist, statt der 65er Bordeaux

[dildo4u]

Wegen F1 2017:

AMDs Grafikkarten laufen in niedrigen Auflösungen schnell ins CPU-Limit

https://www.computerbase.de/2017-08/f1-2017-pc-benchmark/2/

Hat Zero mit Nvidia zu tun,das ganze zieht sich über Jahre bei Rennspielen weil die recht CPU Lastig sind.
AMD läuft hingegen gut bei Dirt 4 weil du dort keine 20 Auto's auf der Strecke hast.

[AffenJack]

Schau dir die Ergebnisse hier an.
Immer noch dumm gelaufen??
https://youtu.be/HL_WnNO7s-c

Und was soll ich da sehen? Die 1070 ist schneller, aber bei AMDs Vega Treiber hätte ich Zweifel, dass da schon groß auf das Spiel optimiert wurde. Generell hat die Performance aber nix mit Gameworks zutun, weil davon neben HBAO nix drin ist und AMD da eher froh sein sollte, wenn das aktiviert wird.

Wegen F1 2017:
Hat Zero mit Nvidia zu tun,das ganze zieht sich über Jahre bei Rennspielen weil die recht CPU Lastig sind.
AMD läuft hingegen gut bei Dirt 4 weil du dort keine 20 Auto's auf der Strecke hast.

Codemastersspiele liefen Jahrelang gut auf AMDs wegen Forward+, was Nv nicht so zu schmecken scheint. Deswegen performt Dirt4 wohl auch so gut. Aber hat F1 2017 das noch?
Achtung Ironie: Oder ist jetzt die fiese von AMD entwickelte Technologie, die Nvidia-Spielern ihr Leben vermiest endlich rausgeflogen und der Grafikmarkt kann aufatmen?

[aufkrawall]

Aber hat F1 2017 das noch?

afaik hatten die schon bei 2016 auf einen Deferred Renderer umgestellt. Ohne MSAA (für VR) ist D+ ja laut mehreren Entwicklern einfach ineffizienter als fully deferred.

[gravitationsfeld]

Das kommt darauf an was man macht. Wenn man nicht hunderte Shader-Wechsel im Frame hat ist F+ problemlos und schneller (was auch den Konsolen hilft).

[Hugo40]

Wegen F1 2017:

https://www.computerbase.de/2017-08/f1-2017-pc-benchmark/2/

Hat Zero mit Nvidia zu tun,das ganze zieht sich über Jahre bei Rennspielen weil die recht CPU Lastig sind.
AMD läuft hingegen gut bei Dirt 4 weil du dort keine 20 Auto's auf der Strecke hast.
Leider übersieht Computerbase dabei, dass Pascal in 1080p ebenfalls stark im CPU-Limit hängt. Eine GTX 1080TI ist nicht nur 13% schneller als eine GTX 1080. Der prozentuale Unterschied beim Wechsel auf 1440p ist bei Pascal und Vega identisch. Bei der GTX 1080TI verdoppelt sich der Abstand zur GTX 1080 bei der höheren Auflösung gegenüber 1080p. Bei Vega 64 vs. Vega 56 auch.

[Gimmick]

*Push*

Es gibt nVidia Flex 1.1.0 auf Softpedia ohne Registrierung zum Download:
http://www.softpedia.com/get/Programming/SDK-DDK/NVIDIA-FleX.shtml

Läuft auch auf AMD GPUs.

Bei den Flüssigkeiten hat die r9 290 hier im Gegensatz zur 1080 ti natürlich gut zu kämpfen (ruckelt aber nix), würde mich mal interessieren wie das auf einer Fury und Vega läuft.

[dargo]

Läuft das überhaupt über die GPU? Meine Vega taktet da mit ~200 bis 300+Mhz bei der GPU. :freak:

[Gimmick]

Läuft das überhaupt über die GPU? Meine Vega taktet da mit ~200 bis 300+Mhz bei der GPU. :freak:

:uponder:

Im Ultra-Schnelltest auf der 290 gabs quasi Null CPU-Last und dafür 100% GPU-Last. Von daher schon auf der GPU irgendwie ja :D

//Ich schau nochmal

[dargo]

Ah... bei Game Mesh Fluid sehe ich teilweise ~1,5Ghz. Das Zeug ist aber kaum reproduzierbar messbar. Ich sehe hier mal 49 min.fps, mal 84 min.fps, mal 100+ min.fps. :freak: Eventuell ein Problem vom Fenstermodus? Zudem limitiert oben Vsync mit 144fps.

[Gimmick]

Grade nochmal "Rock Pool" getestet. Auf "Emit particles" geklickt und gewartet bis keine neuen Partikel mehr erzeugt werden:

r9 290 35 fps 100% Last

Meine 1080 ti bekomme ich so im Fenster und mit VSync nicht ausgelastet, kann aber immerhin sagen, dass die GPU-Auslastung bei der CUDA-Version bei gleichen FPS höher ist.

[dargo]

In welcher Auflösung testest du überhaupt. Weil maximiertes Fenster ist natürlich wesentlich teurer.

[Gimmick]

In welcher Auflösung testest du überhaupt. Weil maximiertes Fenster ist natürlich wesentlich teurer.

Ohne was zu ändern immer. Ich vermute mal das Standard-Fenster hat immer die selbe Auflösung.

In der *.bat kann man btw. zumindest direkt die GPU wechseln - Onboard Intel HD 4000 hat schwer zu kämpfen :freak:

[dargo]

Ohne was zu ändern immer. Ich vermute mal das Standard-Fenster hat immer die selbe Auflösung.

Achso... dann wird das wohl 720p sein denke ich. Bei "Rock Pool" liegt meine Vega mit 910mV UV bei ca. 117-144fps. Oben wie gesagt durch Vsync limitiert. Hier gibt es minimale Schwankungen bei den min.fps... 114-118 min.fps.

[Achill]

*Push*

Es gibt nVidia Flex 1.1.0 auf Softpedia ohne Registrierung zum Download:
http://www.softpedia.com/get/Programming/SDK-DDK/NVIDIA-FleX.shtml

Läuft auch auf AMD GPUs.

Bei den Flüssigkeiten hat die r9 290 hier im Gegensatz zur 1080 ti natürlich gut zu kämpfen (ruckelt aber nix), würde mich mal interessieren wie das auf einer Fury und Vega läuft.

Dann machen wir doch im Benchmark-Forum ein Thread auf ... https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11614525#post11614525

--
Ohne was zu ändern immer. Ich vermute mal das Standard-Fenster hat immer die selbe Auflösung.

In der *.bat kann man btw. zumindest direkt die GPU wechseln - Onboard Intel HD 4000 hat schwer zu kämpfen :freak:

Achso... dann wird das wohl 720p sein denke ich. Bei "Rock Pool" liegt meine Vega mit 910mV UV bei ca. 117-144fps. Oben wie gesagt durch Vsync limitiert. Hier gibt es minimale Schwankungen bei den min.fps... 114-118 min.fps.

Es gibt ein Fullscreen, VSYNC Off und Benchmark-Modus für die Demo, siehe verlinkten Bench-Thread.

[Gimmick]

Es gibt ein Fullscreen, VSYNC Off und Benchmark-Modus für die Demo, siehe verlinkten Bench-Thread.

Thx.
Scheint ja erstmal gut zu laufen. Jetzt müssen nurnoch Spiele damit erscheinen ;)

[Troyan]

VXAO inkl. Turf in FF15
An: https://abload.de/thumb/finalfantasyxvwindowsqqr1e.png (http://abload.de/image.php?img=finalfantasyxvwindowsqqr1e.png)
Aus: https://abload.de/thumb/finalfantasyxvwindowsj1oo2.png (http://abload.de/image.php?img=finalfantasyxvwindowsj1oo2.png)

Wie in Tomb Raider totschick und verdammt kostspielig. Aber von nichts kommt nichts und klarer #1 bei AOs.

[N0Thing]

Wenn die Screenshots richtig verlinkt wurden würde ich eher sagen, dass das AO des Spiels passender ist und Turf keinen nennenswerten Unterschied macht. Dafür wären die bei Computerbase gemessenen Performance-Einbußen aus meiner Sicht absolut nicht angemessen. Aber vielleicht gibt es bessere Szenen für einen Vergleich, sonst könnte ein Schelm denken, es sei ein Vorbote des gestiegenen Marktanteils von Nvidia, von nichts kommt ja auch nichts.

[dildo4u]

Turf sieht man natürlich nur im Feld.
Ich weiß nicht wo das Problem mit den zusätzlichen Optionen ist.
Das Game muss von 1 Teraflop auf Xbox One bis vermutlich 15 TFLOPS für NV 2018 Karte skalieren.

[Achill]

Wenn die Screenshots richtig verlinkt wurden würde ich eher sagen, dass das AO des Spiels passender ist und Turf keinen nennenswerten Unterschied macht. Dafür wären die bei Computerbase gemessenen Performance-Einbußen aus meiner Sicht absolut nicht angemessen. Aber vielleicht gibt es bessere Szenen für einen Vergleich, sonst könnte ein Schelm denken, es sei ein Vorbote des gestiegenen Marktanteils von Nvidia, von nichts kommt ja auch nichts.

Es gibt stellen im Benchmark (FFXV), wo man in 1080p mit Standard ~100fps hat (Autofahrt auf der Straße) und auf High es auf 30-40fps einbricht, optisch mag da gern ein Unterschied geben - ich konnte diesen aber auf den ersten Blick nicht ausmachen bis auf das schlechtere TAA.

[gravitationsfeld]

VXAO inkl. Turf in FF15
An: https://abload.de/thumb/finalfantasyxvwindowsqqr1e.png (http://abload.de/image.php?img=finalfantasyxvwindowsqqr1e.png)
Aus: https://abload.de/thumb/finalfantasyxvwindowsj1oo2.png (http://abload.de/image.php?img=finalfantasyxvwindowsj1oo2.png)

Wie in Tomb Raider totschick und verdammt kostspielig. Aber von nichts kommt nichts und klarer #1 bei AOs.
Die sollten sich lieber mal ordentliches Anti-Aliasing anschaffen. Das sieht ja grausam aus.

[Troyan]

Wenn die Screenshots richtig verlinkt wurden würde ich eher sagen, dass das AO des Spiels passender ist und Turf keinen nennenswerten Unterschied macht. Dafür wären die bei Computerbase gemessenen Performance-Einbußen aus meiner Sicht absolut nicht angemessen. Aber vielleicht gibt es bessere Szenen für einen Vergleich, sonst könnte ein Schelm denken, es sei ein Vorbote des gestiegenen Marktanteils von Nvidia, von nichts kommt ja auch nichts.

Turf macht im Benchmark kein Sinn, da nur wirklich in Dynamik bewertbar. Aber VXAO sieht klar besser und vor allem realistischer aus. Das normale AO ist doch falsch und kommt an vielen Stellen kaum zum tragen.

[dildo4u]

Die sollten sich lieber mal ordentliches Anti-Aliasing anschaffen. Das sieht ja grausam aus.
Schätze mal das ist ein Bug wenn man 1440p Erzwingt?Es müsste so aussehen.

1080p

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

1440p

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

[Troyan]

Liegt an Ansel. Dort wird die temporale Komponente nicht mit erfasst.

GameGPU hat den Autoabschnitt gemessen und AMD... naja, GCN macht GCN, wenn Tessellation zum Einsatz kommt: http://gamegpu.com/action-/-fps-/-tps/final-fantasy-xv-benchmark-test-gpu-cpu

"Turf" und "Terrain" kosten auf nVidia-Hardware zwischen 12% (1080p) und 8% (2160p).

[fondness]

Das NV-Feature läuft auf AMD nicht gut. Damit konnte man nun wirklich nicht rechnen. Womöglich wieder x64 Tesslation auf den kleinste Stein oder man hat irgendetwas anderes gefunden, was AMD nicht liegt.

[Screemer]

als läge das an tesselation, dass vega so verrissen wird. wieder mal ein vorzeigetitel für gameworks :up:

[Linmoum]

Man möchte besser nicht wissen, was da ab "High" standardmäßig noch so alles zugeschaltet wird und vor allem in welchem Ausmaß.

[dildo4u]

Der AMD Treiber scheint Probleme mit dem Streaming zu haben,die Gameworks Effekte an sich laufen ok.Wenn sie aus dem Auto aussteigen sind die fps auf dem selben Level mit der 1080,obwohl dort Turf im Blickfeld ist.
Dann bei Fischen wieder die selben FPS,man steht auf der Stelle hat also auch dort kein Streaming was die CPU belastet.

https://youtu.be/NKvMdo31v_8?t=1m44s

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

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

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

[Achill]

Der AMD Treiber scheint Probleme mit dem Streaming zu haben,die Gameworks Effekte an sich laufen ok.Wenn sie aus dem Auto aussteigen sind die fps auf dem selben Level mit der 1080,obwohl dort Turf im Blickfeld ist.
Dann bei Fischen wieder die selben FPS,man steht auf der Stelle hat also auch dort kein Streaming was die CPU belastet.
[..]


Warum nicht das Video ~10s früher starten lassen (https://youtu.be/NKvMdo31v_8?t=1m25s), da läuft überhaupt nichts ok mit den GW Effekten in FFXV. Es scheint einfach so, dass HairWorks jetzt keine Probleme auf Vega mehr macht, dafür jetzt andere/neue Sachen sehr wohl.

https://i.imgur.com/PHRQ6mv.jpg

[Screemer]

warum bleiben eigentlich alle karten, bis auf die 1080ti welche bis an die 12gb peakt, ~20-30% unter ihrem max. vram?

[scully1234]

Es scheint einfach so, dass HairWorks jetzt keine Probleme auf Vega mehr macht, dafür jetzt andere/neue Sachen sehr wohl.


Vielleicht haben sie bei Hairworks ja endlich mal den Finger aus den Popo gezogen, und bei den neuen Dingen schlicht nicht die Ressourcen um das zeitnah mit dem notorisch unterbesetzten Team zu stemmen

Kein Grund hier dem Werkzeuglieferanten ,schon wieder zu versuchen, den schwarzen Peter zu zuschieben

Ihr kennt doch den Werbeslogan, mit dem gereiften Wein..., dann bleibt doch auch dabei, und ändert nicht alle Sekunde die strategische Ausrichtung, für das was noch nicht funktioniert ,bei irgend einem neuen Spiel

[TGKlaus]

Der AMD Treiber scheint Probleme mit dem Streaming zu haben,die Gameworks Effekte an sich laufen ok.[/URL]

Man sieht doch ganz klar, das was du sagst überhaupt nicht stimmt.
Die nächste vorsätzliche Fehlinformation deinerseits.

[Platos]

warum bleiben eigentlich alle karten, bis auf die 1080ti welche bis an die 12gb peakt, ~20-30% unter ihrem max. vram?

An welcher Stelle im Video soll das sein? Bist du sicher, dass du nicht auf den RAM Verbrauch schaust?

[Screemer]

An welcher Stelle im Video soll das sein? Bist du sicher, dass du nicht auf den RAM Verbrauch schaust?
got me. das nächste mal etwas genauer schaun. da frag ich mich trotzdem warum das 1080ti system den ram wesentlich voller ballert als die anderen. sollte ja das gleiche testsystem sein.

[Loeschzwerg]

Analyse von Digital Foundry zu Gameworks in FF12:
https://www.youtube.com/watch?v=P1t__a3zVFw

[Darkman.X]

Du meintest wohl eher FF15 / FFXV ;)

[Troyan]

Demo läuft astrein. Keine Ahnung, wieso man den Benchmark in der Form veröffentlicht hat. Sieht deutlich schlechter aus und läuft auch viel schlechter.

VXAO gibt es leider nicht zu aktivieren. Aber Terrain Tessellation (jetzt Geomapping) sieht klasse aus und Turf macht einen schicken, aber auch kostspieligen Eindruck.

[Grendizer]

mit 120% Skalierung, Max + Hairworks und Turf hatte ich konstant 60 fps vsync auf 2560x1440

Ich habe aber keinen Ton!

[Locuza]

[...]
VXAO gibt es leider nicht zu aktivieren. Aber Terrain Tessellation (jetzt Geomapping) sieht klasse aus und Turf macht einen schicken, aber auch kostspieligen Eindruck.
Über einen .exe Trick kann man es für die Demo aktivieren:
Off:
https://pbs.twimg.com/media/DW_q31OU0AArPW-.jpg

On:
https://pbs.twimg.com/media/DW_q2tiVwAAudWK.jpg
https://www.resetera.com/threads/final-fantasy-xv-windows-edition-demo-thread.25835/page-10#post-4968788

[dildo4u]

VXAO läuft laut CB jetzt auch auf AMD in FF15.

https://www.computerbase.de/2018-03/final-fantasy-xv-benchmark-test/2/