AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

@gimmick
Unter dx11 wird es vermutlich mit einem Treiber ausgeliefert werden müssen, unter dx12 entwickelst du wenn - es selbst oder fragst einfach bei AMD an.

Unity und Unreal sollte man distanziert sehen und getrennt betrachten.

Nur als Info: Lüppt in Unity auch unter DX12 mit AMD.

 

[hoffgang]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Wieso lohnt es sich eigentlich mit dir zu diskutieren?

Weil ich ein angenehmer objektiver Diskussionspartner bin. Wenn Dir das nicht behagt, dann verlass doch wie angekündigt das sinkende Schiff. Ansonsten bist du zu einer vernünftigen Diskussion herzlich willkommen.

Ich denke wir haben doch jetzt mitbekommen dass du den Preis zu hoch findest.

Ich bin mit da noch nicht sicher. Repetition ist eine Grundlage des lernens, deswegen schadet ein wenig Wiederholung keinesfalls.

Und "just works" ist nicht dumm, sondern du hast die Aussage einfach nicht verstanden.
Die Aussage sollte den Umbruch hin zu Raytracing unterstützen und markieren, dass seit diesem Turing Launch in den Foren so viel gemeckert wird, liegt nur an den Preisen, aber warum die gestiegen sind ist technisch nachvollziehbar.
Gut, das ignorierst du ja vehement - die technische Seite - und stellst halt hier im Forum nichs anderes da als diese Influencer auf Youtube die einfach nur vom Leder ziehen. Bringt dich im Leben halt nicht weiter.

Spielst du mal wieder die Marketingabteilung von Nvidia und richtest deren miese Aussagen grade? Ja den Umbruch zu Raytracing - deswegen auch "it just works". Umbruch bedeutet, it works some day, until then, take this.
Ich ignoriere die technische Seite überhaupt nicht, ich stelle nur zur Diskussion dass Nvidia underdeliverd hat. Den Mund zu voll genommen, von tollen Features gesprochen die bei weitem noch nicht fertig sind und dafür Mondpreise verlangen. Wie andere Teilnehmer der Diskussion anmerken, es hätte auch andere Wege gegeben, Preise senken, mehr Umsatz machen, weniger Gewinn pro Karte aber insgesamt durch höhere Verkäufe das wieder ausgleichen.

Das Marketing hat nicht versagt, da geht es doch auch wieder nur um den Preis.

Entweder Turing ist zu teuer, oder es liefert zuwenig Leistungssprung für den aufgerufenen Preis. Kannste Dir aussuchen.
Ja es ist die schnellste Karte am Markt - die Zuwächse von der letzten Gen sind eher überschaubar und das neue Featureset kann bislang nicht überzeugen. Dazu der hohe Preis - ergo eher unattraktiv.

Keine Ahnung warum man Dir das immer und immer wieder erklärn mus. Aber das mach ich doch gerne, in der Hoffnung dass es sich für dich lohnt.

 

[Rollora]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Entweder Turing ist zu teuer, oder es liefert zuwenig Leistungssprung für den aufgerufenen Preis. Kannste Dir aussuchen.

Stimmt. Ich mag aber manchmal folgendes Gedankenkspiel: was wenn man die Serie gar nicht neu gemacht hätte, sondern einfach auf die Chips der 1080 Ti ersetzt hätte durch den der 2080, und die 2080 Ti als 1090 Ti oben drauf gesetzt hätte. Dann würde plötzlich ergeben, dass die Preise eigentlich ganz normal sind. Das einzige ist halt der nicht vorhandene Preisverfall nach 2 Jahren. Aber, dass man, wenn man die schnellste Karte nochmal beschleunigt, etwas mehr Geld verlangt ist eigentlich normal. Wenn man sich also die 2080 Ti als weiteres Modell über der Ti und Titan vorstellt, würden die Preise wieder passen.

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Warum es läuft traue ich mich gar nicht erst zu mutmaßen.

Aber ich, AMD liefert den Compiler mit dem Treiber aus, denn wie wir wissen kann der nicht von nV stammen. Die Device API ist diesbezüglich zwar eine optionale Komponente, aber gleichfalls Cuda closed und der Quellcode wird nicht offen gelegt. Wir drehen uns seit dem ersten Post im Kreis.

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Aber ich, AMD liefert den Compiler mit dem Treiber aus, [...]

Den Compile für DX DirectCompute?

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Ich denke schon, sah dazu mal eine Folie. FleX liegt im SOA Format vor. NVidia verweist darauf, dass abweichende GPU Architekturen unterschiedliche Resultate erlangen können, weil mit der Simulation über die Laufzeit und abhängig von der Anzahl der contact planes pro Partikel deterministisch reproduzierbare Zustände auftreten können. AMD dürfte aufgrund des Data layouts so weniger miss caches erzeugen und damit eine bessere cache utilization erreichen. FleX müsste imo 500k Partikel animieren können, mit max 6 contact planes pro Partikel was auch Platz braucht. Ich habe das aber nur noch vage in Erinnerung. Einen Link leider nicht. Anders dürfte es aber nicht machbar sein.

Möglich ist ja auch, dass man anderweitig Zugriff darauf erhält. Auf github habe ich nichts gefunden.

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Werden Programme, die die DirectCompute API nutzen immer zur Laufzeit vom Treiber kompiliert?

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Werden Programme, die die DirectCompute API nutzen immer zur Laufzeit vom Treiber kompiliert?

AMD hat zuletzt die Compilerinfrastructur stark überarbeitet, Frontend und Backend, Multitasking und Speicheradressierung angepasst. Mit HIP bietet man auch eine Cudanahe Sprache an. Vor allem die Laufzeit auf der CPU geschieht unter Cuda über eine C API (hab ich schon hier angemerkt). HIP unterstützt das Device- sowie Speichermanagement von Cuda und erlaubt die Unterstützung aller Profiler oder Debugger aus Cuda . Damit lassen sich auch Cuda Anwendungen und Bibliotheken leichter in eine AMD lauffähige Form überführen. Die Benchmarks sind jedenfalls verheißungsvoll, weil Cuda und hip gleich auf liegen. Vor allem kann AMD die Speicherbandbreite von HBM so endlich mal voll ausnutzen.

Unitys vollständiger dx12 Support wurde erst anfangs des Jahres implementiert, ob ROCm auch schon berücksichtigt wurde ist denkbar. Leider fehlt zu vielem noch die Dokumentation. AMD möchte Cuda damit etwas entgegenstellen, inklusive Deep Learning Bibliothek. Die Uni müsste doch Zugriff darauf haben?

GitHub - ROCm-Developer-Tools/HIP: HIP : Convert CUDA to Portable C++ Code

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

AMD hat zuletzt die Compilerinfrastructur stark überarbeitet, Frontend und Backend, Multitasking und Speicheradressierung angepasst. Mit HIP bietet man auch eine Cudanahe Sprache an. Vor allem die Laufzeit auf der CPU geschieht unter Cuda über eine C API (hab ich schon hier angemerkt). HIP unterstützt das Device- sowie Speichermanagement von Cuda und erlaubt die Unterstützung aller Profiler oder Debugger aus Cuda . Damit lassen sich auch Cuda Anwendungen und Bibliotheken leichter in eine AMD lauffähige Form überführen. Die Benchmarks sind jedenfalls verheißungsvoll, weil Cuda und hip gleich auf liegen. Vor allem kann AMD die Speicherbandbreite von HBM so endlich mal voll ausnutzen.

Ist das ein "Ja", "Nein" oder "Manchmal"?
Wenn das zur Laufzeit kompiliert wird, wie man das von Shadern kennt, kann ja jeder zu jeder GPU, die Direct Compute kann, kompatible Programme schreiben, die dann vom Treiber GPU optimiert kompiliert werden.
Wenn ich jetzt hingehen würde und einen Solver für irgendein Problem über DirectCompute schrieben wollen würde, müsste ich mich ja nicht im geringsten für spezifische Eigenschaften einer GPU interessieren, das macht ja dann der Treiber, oder?

Die Uni müsste doch Zugriff darauf haben?

GitHub - ROCm-Developer-Tools/HIP: HIP : Convert CUDA to Portable C++ Code

Meine Uni-Zeiten sind schon eine Weile vorbei

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Ist das ein "Ja", "Nein" oder "Manchmal"?
Wenn das zur Laufzeit kompiliert wird, wie man das von Shadern kennt, kann ja jeder zu jeder GPU, die Direct Compute kann, kompatible Programme schreiben, die dann vom Treiber GPU optimiert kompiliert werden.
Wenn ich jetzt hingehen würde und einen Solver für irgendein Problem über DirectCompute schrieben wollen würde, müsste ich mich ja nicht im geringsten für spezifische Eigenschaften einer GPU interessieren...

Mit hipify liefern sie LLVM+Clang so aus, dass es zur jeweiligen Cuda support Version passt, was der Treiber definitiv unterstützt. Kommt hipifi einem Solver gleich? Support soll zu Windows und Linux passen.

AMD verzichtete auf den PhysX Solver, weil es langsamer lief. Die Version 3.4.1+ stammt aus 2014 und darüber läuft dann auch die FleX Demo, gleichzeitig wird MSVC (C++ kompilieren) unterstützt.

PS: ...ich poste von einem Handy aus. Bitte etwas Nachsicht.

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Mit hipify liefern sie LLVM+Clang so aus, dass es zur jeweiligen Cuda support Version passt, was der Treiber definitiv unterstützt. Kommt hipifi einem Solver gleich? Support soll zu Windows und Linux passen.

AMD verzichtete auf den PhysX Solver, weil es langsamer lief. Die Version 3.4.1+ stammt aus 2014 und darüber läuft dann auch die FleX Demo, gleichzeitig wird MSVC (C++ kompilieren) unterstützt.

PS: ...ich poste von einem Handy aus. Bitte etwas Nachsicht.

Das meine ich nicht.

Ich meine das ganz rudimentär. Ich schreibe über die DirectCompute API einen Solver, der irgendwas ausrechnet - egal was . Da DirectCompute für GPGPU standardisiert ist, sollte das ja dann auf allen GPUs mit passender Versionsunterstützung laufen.
Ich müsste da keinen Code speziell für Vendor X oder Vendor Y schreiben.

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

NVidias spezieller Compiler (nvcc) separiert den Code, wie soll das gehen? Dann musst du eine Optimization vornehmen. GPGPU nein. Wir sprachen doch über Cuda, oder?

Cuda Device
alloziere Grid
Hosttesting
Blocksize
Devicepointer
Update Kernel
I/O
CPU Code

Die API Aufrufe benötigen spezielle Speicherbereiche und Shared Memory.

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Wir sprachen doch über Cuda, oder?

Ne, über DirectCompute /Compute Shaders.

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Ne, über DirectCompute /Compute Shaders.

Und Cuda ist bei dir was?

Du glaubst doch nicht wirklich, du nutzt die Solverlibary aus dem Toolkit und das wird auf AMD llv ausgeführt. Oder doch? Das ist Cuda closed, wie ich jetzt mehrfach schrieb.

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Und Cuda ist bei dir was?

Wie kommst Du schon wieder auf Cuda und auf LowLevel?
DirectCompute ist DirectX, das ist Microsoft, das hat nichts mit Cuda zu tun. Es gibt parallelen in der Funktionalität, das ist wie OpenGL <-> Direct3D.

Das sind alles eigenständige Frameworks/APIs.

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Wie kommst Du schon wieder auf Cuda und auf LowLevel?
DirectCompute ist DirectX, das ist Microsoft, das hat nichts mit Cuda zu tun. Es gibt parallelen in der Funktionalität, das ist wie OpenGL <-> Direct3D.

Das sind alles eigenständige Frameworks/APIs.

Und Begriffe wie "Interoperabilität" sind Schall und Rauch. Du lässt dann alles Brach liegen, was du mit DX nicht ansprechen kannst oder wie meinst du das? Dann frag dich mal was Cuda mit der Memoryallocation von Microsoft und Vulkan macht, wenn das alles nur einzelne APIs sind (Export-/Importallocation="Direct mapping of allocations and semaphores").

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Du lässt dann alles Brach liegen, was du mit DX nicht ansprechen kannst oder wie meinst du das?

Ja...

Ich rede davon einen simplen Compute Shader über DirectCompute zu schreiben und Du kommst schon wieder mit Cuda an, wo ist da der Zusammenhang?

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Ja...

Ich rede davon einen simplen Compute Shader über DirectCompute zu schreiben und Du kommst schon wieder mit Cuda an, wo ist da der Zusammenhang?

Das kannst du so machen, wenn du meinst das ist sinnvoll. Andere machen das so: https://www.amd.com/Documents/HIP-Datasheet.pdf

Und FleX bringt einen NvFlexCudaSolver mit. Darum ging es ja.

Ubrigens ja habe ich nachgeschaut, dass Unity Plugin ist Beta also auch nichts weiter als eine Art "Demomode".

 

[Gimmick]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Das kannst du so machen, wenn du mienst das ist sinnvoll. Andere machen das so: https://www.amd.com/Documents/HIP-Datasheet.pdf

Und FleX bringt einen NvFlexCudaSolver mit. Darum ging es ja.

Nein, es ging nie um den Cuda-Solver. Es ging von Anfang an um den DirectCompute/DX Solver von Flex.

 

[olletsag]

AW: AMD ist nicht von Nvidias DLSS überzeugt und bevorzugt SMAA- und TAA-Lösungen

Nein, es ging nie um den Cuda-Solver. Es ging von Anfang an um den DirectCompute/DX Solver von Flex.

So wie ich das herauslese soll man ab v1.1.0 und direct3d die Flex API überarbeiten, weil es ab der Version eine "New buffer-centric API" eingeführt wurde. Ich kann mir dahe rnicht vorstellen das ein Solver für alle GPUs reicht, Direct Compute hin oder her. Was soll das auch mit Microsoft zu tun haben, denen geht FleX sicher am Hintern vorbei.

Wenn man hipify Inhalten glaubt, kann AMD mit einem HCC Compiler und der dazugehörigen API Cuda für GCN übersetzen, warum soll man dann darauf verzichten?

NVidia schreibt tatsächlich von NewFlexDevice Libary (GPU handling), aber immer im Zusammenhang mit Cuda.