News Licht in Spielen: AMD patentiert eigene Raytracing-Technologie

yurij schrieb:
Und diese werden durch HW beschleunigte Intersection Berechnungen auf den Textureinheiten unterstützt.
Also im Prinzip das, was auch die RT Kerne machen.
 
  • Gefällt mir
Reaktionen: .Sentinel.
Sunjy Kamikaze schrieb:
Die frage ist.. würde dann Raytracing mit AMD in Games anders aussehen als mit Nvidia? Ansich sollte doch beides das Licht Realistisch berechnen oder?

Grundsätzlich sollte man erwarten können, dass das selbe Ergebnis heraus kommt. Aber es könnte natürlich sein, dass einzelne RT-Effekte auf Nvidias und AMDs Umsetzungen unterschiedlich viel Leistung kosten. Dann wäre es denkbar, dass ein Spiel vorab prüft, was für eine GPU im System steckt, und gegebenenfalls bei aktiviertem RT auf bestimmte Effekte verzichtet oder sie anders/sparsamer umsetzt usw.
 
  • Gefällt mir
Reaktionen: .Sentinel. und Transistor 22
HardRockDude schrieb:
wag ich nach der im März vorgestellten Demo aber etwas zu bezweifeln :)
Das ist aber schon nicht ganz vergleichbar. Die Crytek-Demo hielt gewisse Informationen zurück und ob man einen vordefinierten Kameralauf mit einem Spielgeschehen vergleichen kann, ist auch fraglich. Dazu kommt eben, wieviel Last auf der GPU liegt und mit wie vielen Frames das ganze dann läuft. Die Crytek-Technik verwendet dazu noch einige Tricks mehr für die Berechnung (was nicht heißen soll, dass es schlecht ist, nur eben anders)
 
Mar1u5 schrieb:
Die Konsolen werden dann bestimmt mit 8k, 144Hz, HDR, Raytracing beworben :freak:
Die Konsolen-Kidz werden es eh nicht merken.
 
  • Gefällt mir
Reaktionen: .Sentinel., yummycandy, Tzk und 3 andere
Herdware schrieb:
Vielleicht sind damit auch nur die Textur-Einheiten (TMU) gemeint, die es sowieso auf jeder (halbwegs modernen) GPU gibt. Eventuell mit speziellen Anpassungen/Erweiterungen, so dass sie zusätzlich auch RT beschleunigen können.
Im Patent wird ja darauf hingewiesen, dass der Shader die Steuerung übernimmt (Software) und die Textureinheit quasi für den Hardwarebasierten Ansatz steht.
Im Vergleich zur NV Lösung, soll man unter anderem an Die Fläche Sparen und man benötigt auch keine große Puffer und nützt die Speicherpool der Textureinheit.

Sprich, man hat per Software laut Patent mehr Freiheiten, hat aber natürlich etwas weniger Performance als die RTX Variante, aber deutlich besser als rein per Software.
Kurz interessant wie gut das funktioniert und ob durch "gewonnene" Die-Size, man das dafür mit mehr Shader kompensieren kann.
Auch ist die weit aus mehr "programmable" Variante interessant für andere Umsetzungen die nicht direkt mit Spiegelung von Objekten zu tun haben und die Genauigkeit nicht so hoch sein muss.

Toprallog schrieb:
Natürlich fressen die eine Menge Strom und werden dadurch sehr warm. Aber einen (großen) Chip zu kühlen auf einer recht kleinen Fläche, wie einer Grafikkartenplatine, stelle ich mir einfacher vor, als einen weiteren Chip zu kühlen.
Es ist kein weiterer Chip. Es wurde einfach im Deutschen als TexturProzessor übersetzt.

796109

796110


https://en.wikipedia.org/wiki/Texture_mapping_unit
A texture mapping unit (TMU) is a component in modern graphics processing units (GPUs). Historically it was a separate physical processor.
Today (2013), TMUs are part of the shader pipeline and decoupled from the Render Output Pipelines (ROPs). For example, in AMD's Cypress GPU, each shader pipeline (of which there are 20) has four TMUs, giving the GPU 80 TMUs. This is done by chip designers to closely couple shaders and the texture engines they will be working with.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Hatch und Ozmog
Sollte dieser Ansatz vernünftig und durch leistungsgerechte Preise funktionieren, so wird das Tor raus aus der Nische hin zum Massenmarkt aufgestoßen werden.
 
Also sehen wir die zweite Generation der RDNA-Architektur bei der Navi 21?
 
Toprallog schrieb:
Aber ein eigenständiger Texturprozessor auf der Grafikkarte erschwert das Platinenlayout, muss zusätzlich gekühlt werden und wird auch gut Strom fressen.
Ich sehe da keine Probleme den man könnte den Texturprozessor in das Chip Design integrieren oder als zweiten Chip mit dem gleichen CHip Gehäuse nutzen ohne irgendetwas zusätzlich zu kühlen. Da ich aber davon ausgehe dass der CHip in 7nm gefertigt wird gehe ich persönlich von der 2 DIE Variante aus. Man hat inzwischen ausreichen Erfahrung mit multichip Designs gesammelt und die kleinere Chip Größe in Verbindung mit dem weniger komplexen Chip Design sollte auch die Ausbeute verbessern und damit die Kosten minimieren.
Es kann aber auch genauso gut sein das die Chip Fläche des Textur Prozessors so gering wäre dass es die Chipfläche kaum vergrößern würde, in dem Fall ist natürlich eine singlechip Lösung vorzuziehen.
Zu der Stichelei wegen HBM, wo soll da der Bezug zum Thema sein?
Die HBM(2) Lösung ist aus 2 Gründen so teuer, das komplexe Interposer Design und der hohe Preis vom Speicher selbt.
Toprallog schrieb:
Natürlich fressen die eine Menge Strom und werden dadurch sehr warm. Aber einen (großen) Chip zu kühlen auf einer recht kleinen Fläche, wie einer Grafikkartenplatine, stelle ich mir einfacher vor, als einen weiteren Chip zu kühlen. Dabei bleibt es ja nicht. Spannungsversorgung und RAM sind ja auch kühlpflichtige Komponenten.
Bei der 2080Ti hat NV ja scheinbar reichlich Probleme gehabt, ein 2-Chip-Design macht es nicht unbedingt einfacher/günstiger.
ob sich ein Multichip Design lohnt hängt vor allem von der Größe der einzelnen Chips und die zu erwartene Chip Ausbeute ab. Mit zunehmender Größe des Chips nimmt natürlich auch die Angriffsfläche für Defekte zu die den Chip beschädigen oder gar zerstören können, deshalb nimmt die Ausbeute an voll funktionstüchtigen Chips auch mit zunehmende Chip Größe (beim gleichen Fertigungsprozess) erheblich ab.

Roche schrieb:
Nett, dass auch AMD sich mit dem Thema beschäftigt.
Allerdings hätte ich von denen viel lieber mal wieder gescheite neue Grafikkarten mit ordentlich Leistung bei gleichzeitig angemessenem Stromverbrauch und einem fairen Preis.
Das ist mir viel wichtiger als irgendwelche Raytracing Effekte.
Die Erfahrung hat gezeigt das es sich offensichtlich nicht für AMD rentiert solche Karten zu entwickeln weil sie vom Großteil der Kundschaft ohnehin nur als Preisdrücker für die Geforce Karten angesehen werden.
Deshalb verstehe ich auch die Ausrichtung der Entwicklung auf die Konsolen- und teure, professionelle Designs voll und ganz.
Wer an den Karten interessiert ist kauf sie im Zweifelsfall auch ohne sich mit Preisbrechern die eigenen Zahlen zu verhageln und die Entwicklungskosten der entsprechenden Chips werden dann eben von den entsprechenden Marktsegmenten getragen.
Irgendwie doof für PC Spieler wie mich aber immernoch besser als sich wegen Unrentabilität komplett aus dem PC Spielerkarten Markt zurück zu ziehen.
 
  • Gefällt mir
Reaktionen: cbmik und edenjung
Erinnert mich irgendwie stark an meine Arbeit http://wcms.uzi.uni-halle.de/download.php?down=18403&elem=2440215 aus dem Jahr 2009 (SM 3.0), nur dass sie jetzt die RT-Intersection in Hardware in der Textureinheit durchführen wollen (und das Octrees durch BVH-Trees ersetzt wurden, was ich für die Arbeit auch überlegt hatte, aber dann auch verworfen hatte, da die Geometrie BVH-Trees unterstützen muss.)

Ansonsten ist die Kommunikation über Texturen anscheinend die gleiche ... nur 10 Jahre Später 😃
796111
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Colindo, Excel, edenjung und 6 andere
rikko11 schrieb:
Warum sollte sich Sony, mit AMD HW an den von Nvidia benützten Microsofts Standard DXR halten ?
Was Sony macht, ist hier erst einmal egal. Interessant ist eben was AMD macht und die werden schlecht beraten jenseits von Microsofts DXR einen separaten weg einzuschlagen. AMDs Marktanteil für PCs ist eben viel zu gering, um eine proprietäre Lösung anzustreben, wenn es doch bereits eine verfügbare Lösung gibt. Dazu gibt´s dann ja auch noch die X-Box, die dann auch DXR verwenden möchte.
Entscheidend ist ja, was die Spieleentwickler dann umsetzen.

Wenn es Sony anders umsetzt, dann liegt es an deren API und ein extra RT-Feature. Von Treiber und Hardware muss es dann aber auch umgesetzt werden, und dabei werden bestimmt keine zwei völlig verschiedene Wege beschritten.
 
  • Gefällt mir
Reaktionen: xexex, Fraggball und Strikerking
pipip schrieb:
Im Vergleich zur NV Lösung, soll man unter anderem an Die Fläche Sparen und man benötigt auch keine große Puffer und nützt die Speicherpool der Textureinheit.

Und die TMUs und Shader werden auch im normalen "nicht-RT"-Betrieb genutzt, während Nvidias RTX- und Tensor-Cores dann brach liegen.

Insgesamt klingt AMDs Ansatz eleganter/flexibler, aber es kommt natürlich darauf an, wie schnell RT dann letztlich damit läuft. Wenn Nvidia nicht total daneben gegriffen hat, sollten spezialisierte Einheiten leistungsfähiger sein, als (erweiterte) Allround-Hardware.
 
pipip schrieb:
Sprich, man hat per Software laut Patent mehr Freiheiten, hat aber natürlich etwas weniger Performance als die RTX Variante, aber deutlich besser als rein per Software.

Benchmarks? Link?
 
  • Gefällt mir
Reaktionen: Bright0001
pipip schrieb:
Kurz interessant wie gut das funktioniert und ob durch "gewonnene" Die-Size, man das dafür mit mehr Shader kompensieren kann.
Gerade, wenn es bei AMD bei hohen Shaderzahlen nicht so gut skaliert, was "gewöhnliche" Grafikberechnungen betrifft (wie es bei Navi aussieht, wissen wir natürlich noch nicht).
Die Zusätzliche Berechnung von Raytracing kann dadurch wohl die Auslastung erhöhen und dadurch auch mit vielen Shadern besser skalieren.

Zumindest hat man nicht x Diefläche für dedizierte RT-Einheiten verbraucht, die ja dann nur zum Tragen kommen, wenn auch RT berechnet wird. Und bei wie vielen Spielen ist es bisher der Fall? Ein Aufpreis für ein (bisher) kaum genutztes Feature.
Ergänzung ()

Übersoldier75 schrieb:
Benchmarks? Link?
Nicht mitbekommen, dass es hier um Vermutungen rein auf Basis des Patents geht?
Weniger Performance ist quasi gesetzt, weil eine dedizierte Einheit oder eine Softwareumsetzung eben doch unterschiede bereiten. Dafür ist man eben nicht auf eine begrenzte Anzahl der dedizierten RT-Einheiten beschränkt, also flexibel...
 
Übersoldier75
Such dir die "Benchmarks" von einer reinen Software Lösung (GTX Karten) vs einer RTX Karte und addiere das mit den Fakt, dass Shader programmierbar sind und die TextureUnit mehr oder weniger (falls ich mich nicht irre) eine fix function Prozessor war, der seinen Weg wie vieles andere in die GPU geschafft hat und direkt in der grafik pipline ist.
Sprich kurz, AMD hat die Texture Unit durch weitere Operationen erweitert. Falls ich mich aber irre, lasse ich mich gerne aufklären.

Wenn die Lösung aber nicht schneller wäre, als eine rein Software-basierte Lösung, würde AMD diese Umsetzung kaum machen.
Desweiteren ist klar, GPUs werden weiterhin zu schwach sein für RT. Sieht man ja bei der 2080TI die mit RT eher für FHD beschränkt ist.
Somit kann man stark annehmen, in Zukunft eher beschränkt RT Effekte in Games zu sehen. Somit sehe ich das "programmierbare" eben als einen Vorteil. Während bei NV Lösung der RT Core eben mit den Richtigen Daten gefüttert werden muss. Man ist eben weniger flexibel. Sowas ist aber bei fix function "immer" der Fall.
Wieso auch dauert es so lange, bis SIMD Instructionen ihren Weg in Software finden. Siehe AVX512 Bit.

Aber gut, das ist halt meine Sicht der Dinge.

Ozmog
Mein Gedanke war letztens, die News ist ja nicht so neu, AsyncCompute, was DX12 ja kann und RT sowieso zu DX12 gehört.
 
Nicht doch, nach Meinung einer User hier ist Raytracing doch absolut sinnlos und wird sich nie druchsetzen ... und jetzt macht AMD es auch. Und dann kommt es vermutlich sogar in die neuen Konsolen. Sind die ganzen Leute dort dann auch nur Versuchskaninchen?
Was nun? Koennen sich die User bitte nochmal zu Wort melden?

Ansonsten, ich finde es gut dass beide GPU Hersteller neue Wege gehen. Gut, am besten waere natuerlich ein einheitlicher Weg, aber man kann (noch) noch alles haben, der Rest wird sich erst in 5 Jahren zeigen.
 
Herdware schrieb:
Insgesamt klingt AMDs Ansatz eleganter/flexibler, aber es kommt natürlich darauf an, wie schnell RT dann letztlich damit läuft. Wenn Nvidia nicht total daneben gegriffen hat, sollten spezialisierte Einheiten leistungsfähiger sein, als (erweiterte) Allround-Hardware.

Muss sich halt am Ende zeigen. Bis es entsprechende Produkte von AMD gibt, wirds wahrscheinlich auch schon eine zweite Generation an RTX Cores geben.

Generell war reine Hardwarebeschleunigung in der Geschichte aber immer schneller, als irgendwelche Softwarelösungen. Und für mich sieht das bisher ziemlich nach Softwarelösung aus, nur das man die Architektur entsprechend anpasst und Flaschenhälse verkleinert. Wie das Ergebnis ist? Das werden wir sehen, wenn die Karten verfügbar sind. Aber man kann sehr gespannt sein! Damit wird Echtzeit Raytracing in Spielen wahrscheinlich massenmarkttauglich.

AMD ist am Ende aber natürlich mit dem Ansatz flexibler.

Ozmog schrieb:
Zumindest hat man nicht x Diefläche für dedizierte RT-Einheiten verbraucht, die ja dann nur zum Tragen kommen, wenn auch RT berechnet wird. Und bei wie vielen Spielen ist es bisher der Fall? Ein Aufpreis für ein (bisher) kaum genutztes Feature.


Die Diefläche kann einem als Kunden ja am Ende des Tages auch relativ egal sein. AMD Verlangt ja für die kleinen Mittelklasse Chips auch das gleiche Geld, wie Nvidia für die deutlich größeren. Wir wissen Stand heute einfach auch zu wenig.

Es wird noch Zeit ins Land gehen, bis wir die entsprechenden AMD Chips sehen und wenn die Kommen, dürfte auch bei Nvidia bald eine neue Generation ins Haus stehen, zu der man ja auch bisher wenig weiß. Kann auch gut sein, dass Nvidia die zusätzlich benötigte Fläche noch mal ein stück senken kann.

Aber wenn ich mich recht erinnere, dann nehmen nicht die Raytracing Cores so viel Platz ein, sondern die Tensor Cores. Und hier hat AMD bislang keine Alternative. Ich denke aber auch, dass wird die bei AMD auf reinen Gamingkarten nicht sehen werden. Auf den Profikarten wäre es aber wünschenswert. Die Tensorcores machen die Nvidia Karten nicht nur für Gamer interessant.

Aber generell sollten deutlich mehr Spiele mit Raytracing Unterstützung auf den Markt kommen, wenn die Konsolen das Feature auch unterstützen und die meisten PC Grafikkarten das auch können. Dann bleibt die zusätzliche Fläche auch nicht unbedingt ungenutzt ;)
 
Ozmog schrieb:
Nicht mitbekommen, dass es hier um Vermutungen rein auf Basis des Patents geht?

Ohne Beweise sollte man mit seinen Vermutungen vorsichtig sein! Vermuten kann ich auch viel!

pipip schrieb:
Such dir die "Benchmarks" von einer reinen Software Lösung (GTX Karten) vs einer RTX Karte und addiere das mit den Fakt, dass Shader programmierbar sind und die TextureUnit mehr oder weniger (falls ich mich nicht irre) eine fix function Prozessor war, der seinen Weg wie vieles andere in die GPU geschafft hat und direkt in der grafik pipline ist.

Du vergleichst hier "Äpfel" mit "Birnen"! Ich will Fakten! und die gibt es noch nicht! Oder bist du ein "Analyst"!🈹
 
  • Gefällt mir
Reaktionen: Bright0001
Was mich dabei interessiert ist ob Spiele für die AMD oder die Nvidia Version unterschiedlich programmiert werden müssen.

Wenn ja geht das unterschiedliche Spiele laufen nur auf bestimmten Karten gut weiter, weil die Spieleentwickler wohl weiter nur für einen Anbieter optimieren werden.

Man kann bloß hoffen das die unterschiedlichen Ansätze zu 100% kompatibel sind.
 
Zurück
Oben