Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsStarfield: Bethesda will DLSS, FOV-Regler und Essen-Taste nachreichen
Das mag ja sein. Du bist also dafür, dass wir jeweils zwei GPUs kaufen, eine von AMD und eine von nVidia? Weil sollte diese Ansicht, die Du vertritts weitergeführt werden, dann sind wir wieder, wo wir Anfangs den 90ern waren, wo Spiele nur mal auf dem einen und mal auf dem anderen Hersteller (da gab es immerhin noch paar mehr) lief.
Nein genau dafür bin ich nicht.
DLSS, XeSS und FSR setzen alle an der selben Stelle an und können daher auch ohne größeren Aufwand alle 3 gleichzeitig von den jeweiligen Studios implementiert werden.
Nvidia hat ja sogar die Grundlage dafür geschaffen.
FSR könnte wesentlich besser sein wenn AMD sich voll auf ihre eigene Hardware konzentriert, das heist aber nicht das Entwickler sich dann für eine der möglichen Lösungen entscheiden müssen. Die Grundlage dafür das sie genau das nicht müssen ist bereits geschaffen.
AMD könnte den Wechsel morgen ankündigen und es müsste für niemanden Nachteile haben. Außer natürlich alle 3 Seiten fangen dann an Entwickler dafür zu bezahlen das die Konkurrenz Upscaler nicht vorhanden wären aber sowas könnte man ja durchaus im Vorfeld bereits verhindern wenn sich AMD Intel und Nvidia an einen Tisch setzen und Streamline gemeinschaftlich nutzen und irgendeine Spiele exclusive Upscaler Kacke direkt vertraglich ausschließen.
Ist aber vermutlich Wunschdenken meinerseits das sowas mal passiert.
Ganz so einfach ist das dann auch nicht wie du jetzt tust.
Das ganze X86-64 Thema ist bischen komplexer als das man einfach so tun könnte das AMD aus goodwill Intel eine Lizenz gegeben hätte.
Die "Quelle" ist verlinkt, freigeschaltet war SAM nur für aktuelle CPUs, und erst im Nachhinein hat man nach Rechtfertigungen gesucht und es später auch für ältere AMD CPUs freigeschaltet.
Eine weitere Neuerung der Radeon RX-6000-Serie kommt nur in Zusammenhang mit AMDs neuesten CPUs zum Zuge. Wer eine Radeon-RX-6000-Grafikkarte auf einer Ryzen-5000-CPU auf Basis von Zen 3 betreibt, soll in Spielen eine bessere Performance erhalten. Nicht nur aufgrund der höheren Rechenleistung von Ryzen 5000 sei das der Fall, sondern weil bei dieser Hardware-Kombination auch der Prozessor Zugriff auf den gesamten GPU-Speicher hat. AMD nennt das „Smart Access Memory“. Weitere Details zu der interessant klingenden Technologie gibt es noch nicht.
Eben mich wundert das die Leute von der Bude was anderes erwartet haben. Ich denke ohne Microsoft wäre Starfield in einem noch sehr viel schlechteren Zustand rausgekommen.
Mit Logik werden wir da wohl nichts. Ich könnte mir vorstellen, dass aufgrund der Bedeutung für Gamepass und XBox hier Schwerpunkte gesetzt wurden.
Konsole -> AMD -> FSR -> Optimierung, damit es (vor allem) dort trotz seiner Größe vernünftig läuft. Also wurden die Stärken der AMD-GPU ausgereizt und in diesem Zuge Nividia-GPUs vernachlässigt.
Ist aber nur eine Vermutung ohne Nachweis der Korrektheit.
Nein genau dafür bin ich nicht.
DLSS, XeSS und FSR setzen alle an der selben Stelle an und können daher auch ohne größeren Aufwand alle 3 gleichzeitig von den jeweiligen Studios implementiert werden.
Und trotzdem wird es nicht gemacht, weil eben auch "kein grösserer Aufwand", Aufwand ist. Es gibt dutzende Beispiele, wo XeSS komplett fehlt, FSR erst viel später (und oft auch noch in nicht aktueller Form) implementiert wird, oder auch DLSS mal fehlt.
Atnam schrieb:
Nvidia hat ja sogar die Grundlage dafür geschaffen.
Ich kenn mich im technischen Detail nicht aus. Aber es wird einen Grund geben, warum das weder von Intel und AMD unterstützt, noch von den Entwicklerstudios genutzt wird.
Atnam schrieb:
FSR könnte wesentlich besser sein wenn AMD sich voll auf ihre eigene Hardware konzentriert, das heist aber nicht das Entwickler sich dann für eine der möglichen Lösungen entscheiden müssen. Die Grundlage dafür das sie genau das nicht müssen ist bereits geschaffen.
So wie ich das verstanden habe, ist Streamline lediglich eine API um die notwendigen DLLs anzusteuern (für alle 3 Upscaling Technologien). Das heisst aber nicht automatisch, dass diese dann auch sauber funktionieren. Nicht mal bei DLSS ist das der Fall, wie die Starfield Mods, die auf Streamline basieren (soweit ich das verstanden habe) und trotzdem teilweise Probleme bereiten.
Ganz so einfach wie ein standardisiertes DirectX ist Streamline offenbar nicht.
Atnam schrieb:
Ganz so einfach ist das dann auch nicht wie du jetzt tust.
Das ganze X86-64 Thema ist bischen komplexer als das man einfach so tun könnte das AMD aus goodwill Intel eine Lizenz gegeben hätte.
Es war ja nur ein Beispiel. Es gibt noch diverse andere, wo das mit Lizenzen funktioniert. DirectX, AVX, ARM...
Ergänzung ()
xexex schrieb:
Die "Quelle" ist verlinkt, freigeschaltet war SAM nur für aktuelle CPUs, und erst im Nachhinein hat man nach Rechtfertigungen gesucht und es später auch für ältere AMD CPUs freigeschaltet.
In der Quelle steht aber nix davon, dass rBar-fähige nVidia und Intel GPUs ausgeschlossen wurden. Also gab es kein Vendor-Lock und auch keine Benachteiligung von nVidia seitens AMD. AMD hat die Funkion auf allen Grafikkarten ermöglicht, die es unterstützen und so den Performancevorteil auch nVidia und Intel ermöglicht.
Ist auch so, Chipsatz und CPU müssen die Technik unterstützen. Das es bei älteren, nicht mehr aktiv unterhaltenen Chipsätzen und Grafikkarten fehlt und nicht mehr nachgereicht wird, sowohl bei AMD als auch bei Intel, ist doch nachvollziehbar.
Stimmt, böses AMD, supporten einfach die EOL GPUs nicht mehr. Das ist nur in Ordnung wenn man GPUs noch neu verkauft, nVidia heisst,und die aktuelle Technikhinterartion trotzdem nicht im Treiber freischaltet (DLSS3 auf Ampere)
Ändert aber nach wie vor nix daran, dass AMD eine Technologie, die Performancevorteile bei GPUs brachte, sowohl für sich selbst, als auch für die Konkurrenz offen gemacht hat.
Kannst mir ja mal ein Beispiel von nVidia bringen, falls Du eins findest.
In der Quelle steht aber nix davon, dass rBar-fähige nVidia und Intel GPUs ausgeschlossen wurden. Also gab es kein Vendor-Lock und auch keine Benachteiligung von nVidia seitens AMD.
Nochmal! AMD hat Resizable Bar nicht erfunden, sie konnten es also nicht für andere Hersteller blockieren. Sie haben es aber für eigenen Kunden blockiert, was noch schlimmer gewesen ist und für mich zu einen der vielen AMDs "dickmoves" gehört.
AMD sieht den auf Resizable BAR basierenden Smart Access Memory (SAM) speziell für Ryzen 5000 (Test) auf Basis von Zen 3 und den Chipsätzen X570 und B550 (Test) vor, doch der Speichervollzugriff auf den VRAM der Grafikkarte funktioniert auch mit den Core-CPUs von Intel, den PCHs X470 und B450 sowie auf Renoir und Matisse.
Wunderbar, überall präsent, Raytracing. Ohne Nvidias Vorstoß und die Arbeit daran, würden wir weder Raytracing unter Windows, noch in der Vulkan API haben. Unter Vulkan wurden die von Nvidia geschriebenen RTX Extensions fast 1zu1 in die API übernommen. https://www.khronos.org/blog/ray-tracing-in-vulkan
Ich kenn mich im teschnischen Detail nicht aus. Aber es wird einen Grund geben, warum das weder von Intel und AMD unterstützt, noch von den Entwicklerstudios genutzt wird.
Nur das Intel Streamline anscheinend offiziell unterstützt weil sie auf Nvidias Streamline Website namentlich genannt werden und AMD wiederum nicht genannt sondern nur als "Hardware Vendor #3" aufgeführt wird.
Ob und wie Studios Streamline nutzen weist du doch gar nicht. Also was soll die Behauptung das es niemand nutzt?
CadillacFan77 schrieb:
So wie ich das verstanden habe, ist Streamline legidlich eine API um die notwendingen DLLs anzusteuern (fpr alle 3 Upscaling Technologien). Das heisst aber nicht automatisch, dass diese dann auch sauber funktionieren. Nicht mal bei DLSS ist das der Fall, wie die Starfield Mods, die auf Streamline basieren (soweit ich das verstanden habe) und totzdem teilwese Probleme bereiten.
Das hast du richtig verstanden. Sagt auch niemand das Streamline fehlerfrei ist. Es ist auch nur eine Feature das stetig weiterentwickelt wird. Genau so wie FSR oder DLSS oder XeSS.
Nochmal! AMD hat Resizable Bar nicht erfunden, sie konnten es also nicht für andere Hersteller blockieren. Sie haben es aber für eigenen Kunden blockiert, was noch schlimmer gewesen ist und für mich zu einen der vielen AMDs "dickmoves" gehört.
Wunderbar, überall präsent, Raytracing. Ohne Nvidias Vorstoß und die Arbeit daran, würden wir weder Raytracing unter Windows, noch in der Vulkan API haben. Unter Vulkan wurden die von Nvidia geschriebenen RTX Extensions fast 1zu1 in die API übernommen. https://www.khronos.org/blog/ray-tracing-in-vulkan
Raytracing gibts seit den 80ern. Das ist nix Neues.
Dein Artikel war sehr spannend, aber ich lese da nix von RTX Extensions 1:1 übernommen.
by Daniel Koch, NVIDIA, Vulkan Ray Tracing TSG Chair, @booner_k
Tobias Hector, AMD, @TobskiHectov
Joshua Barczak, Intel, @JoshuaBarczak
Eric Werness, NVIDIA
"ISVs were also very clear—we needed to enable content using contemporary proprietary APIs, such as NVIDIA OptiX™ or Microsoft DirectX Raytracing, to be easily portable to Vulkan. Consequently we used a familiar overall architecture, including the re-use of HLSL shaders, while also introducing new functionality and implementation flexibility."
Die verwendeten Shader basieren auf HLSL (Microsoft D3D) oder GLSL (Teil von OpenGL):
"Developers can generate these binaries using either GLSL or HLSL. For GLSL, there are three new GLSL extensions: GLSL_EXT_ray_tracing, GLSL_EXT_ray_query, and GLSL_EXT_ray_flags_primitive_culling, which are supported in the open source glslang compiler. HLSL support is also provided via DXC, Microsoft's open source HLSL compiler, allowing Vulkan ray tracing shaders to be authored in HLSL using the syntax defined by Microsoft, with minimal modifications. Both glslang and DXC are included as part of the Vulkan SDK ."
Es ist nun wirklich nichts neues, dass die Khronos Gruppe gar nichts in der Hand hatte, als Nvidia die Erweiterungen veröffentlicht hatte. Die sind später genauso in der API gelandet wie Nvidia sie entwickelt hat.
The Ray Tracing TSG was formed in early 2018 and tasked to bring a tightly integrated, cross-vendor, ray tracing solution to Vulkan. In March 2020, the provisional ray tracing extensions were released to gather public review and input into the final design of these extensions. On November 23, 2020, the final specifications were released and on December 15, 2020 the Vulkan 1.2.162.0 SDK was announced, which incorporated support for these extensions, enabling developers to be able to easily integrate Vulkan Ray Tracing into their applications.
Du scheinst mehr von dem Thema zu verstehen als ich - Diese Erweiterungen (Extensions), muss man die als "Befehlszeilen" oder als "Programcode" verstehen?
Aus Deinem ursprünglich verlinkten Artikel verstehe ich es so, dass die genannten Extensions Befehlsketten sind um RT zu adressieren, die Umsetzung / Berechnung geschieht jedoch mittles GLSL respektive HLSL Shadern.
Was mir auch nicht klar ist, warum RTX Befehle 1:1 konvertiert werden müssen. Wenn es 1:1 ist, und offen, dann ist das doch total unnötig?! wozu braucht es dann nV "native" Extensions und in Vulkan "konvertierte" Extensions? Wenn es das Gleiche ist, warum braucht es diese Unterscheidung?
Du scheinst mehr von dem Thema zu verstehen als ich - Diese Erweiterungen (Extensions), muss man die als "Befehlszeilen" oder als "Programcode" verstehen?
Stell sie dir vor als Spielemods, wo dann der Hersteller es irgendwann als festen Bestandteil integriert. Als Nvidia Raytracing auf den Markt brachte und Microsoft eine fertige API präsentierte, gab es in der Khronos Gruppe nicht einmal eine Arbeitsgruppe die sich mit dem Thema befasst hätte. Da Nvidia jedoch nicht einzig DX12 als die API für RT sah und viele damals noch an einen Kopf an Kopf Rennen der beiden APIs glaubten, wurden schlichtweg die Module/Mods von Nvidia geschrieben, damit man auch unter Vulkan auf RT Hardware zugreifen kann. Die API Erweiterungen wurden dann weitgehend 1zu1 in Vulkan übernommen, natürlich später auch mit Beteiligung von AMD und irgendwann ebenfalls Intel.
Grundsätzlich hätte es aber auch wie früher mit OpenGL laufen können, da hätte dann jeder Hersteller seine eigenen Erweiterungen geliefert. Man hätte das gleiche Chaos und Entwicklungsrückstand wie unter OpenGL gehabt und jede Karte müsste mit eigenem Befehlssatz angesprochen werden. https://de.wikipedia.org/wiki/OpenGL
OpenGL hat man seinerzeit "zur Tode" erweitert, weil sich jeder Hersteller nur um den eigenen Kram kümmerte, die eigentliche "Kern-API" rutschte hingegen in die Bedeutungslosigkeit.
