G
gaussmath
Guest
Und ich find's super, dass du nun ein Teil der Community bist und man solche Sachen mit dir in Ruhe diskutieren kann.
Intel Xe: Hinweise auf Raytracing-Support
- Ersteller PCGH-Redaktion
- Erstellt am
Und ich find's super, dass du nun ein Teil der Community bist und man solche Sachen mit dir in Ruhe diskutieren kann.
Das dick Markierte ist eine Grundvoraussetzung dafür, dass sich die Ausgabe auf dem Bildschirm nicht unterscheidet. Bei Schnittpunktberechnungen gibt es nunmal nur EIN richtiges Ergebnis.
Die Einheiten, die das berechnen, müssen somit zum gleichen Ergebnis kommen.
Intersections of Rays, Planes and Triangles (3D)
Genau- Es kann sogar sein, dass AMD mit einer ganz anderen Lösung um die Ecke kommt. Das Patent ist ja nur eine Beschreibung einer Methodik.
Ohne miteinbeziehung einer hardwired- Lösung wirds aber geschwindigkeitstechnisch nichts werden...
Universelles compute ist diesbezüglich noch deutlich zu schwach auf der Brust.
Exakt. Deshalb schreibe ich ja regelmäßig dazu, dass sich meine Ausführungen auf das Patent und den bis jetzt getätigten Aussagen von AMD selbst beziehen.
Da die Methodik einer Schnittpunktberechnung fest steht, als es auch nur ein gültiges Ergebnis dieser Berechnungen geben kann, ist das in diesem Punkt aber einfach so.
Ist möglich und wahrscheinlich.
Das wäre eine von vielen Möglichkeiten. Eine andere wäre durch einen beschleunigten Sortieralgorithmus die Strahlenkohärenz zu erhöhen, da der Cache durch die Diffusität des Verfahrens wenig Wirkung entfalten kann.
Das verhindert man dadurch, indem man die RT Corezahl so hoch gewählt hat, dass man diesbezüglich auf absehbare Zeit nicht ins Limit gerät.
Die knapp 10 Gigarays die auf der 2080 TI zur Verfügung stehen (der Wert wird auch in der Praxis knapp erreicht- Prüfbar im Visual Studio), würden in der Theorie ausreichen um 4K 60FPS mit 20Rays/Pixel abzutasten.
Da machen die Shader in der Praxis, die die Ergebnisse dann "umsetzen" müssen schon viel früher zu. Gerade weil sie eben "nebenbei" noch ein gesamtes AAA Spiel stemmen müssen.
Das zwingt die Hersteller im Augenblick zu einem Kompromiss. Entweder hohe RT Qualität oder eben hohe raster- Qualität. Zwischen diesen beiden polen tarieren die Entwickler hin- und her.
Schön, dass wir langsam dahin kommen, "normal" miteinander zu "reden", auch wenn Du nicht auf meine einfachen Fragen antworten möchtest.
LG
Zero
Zuletzt bearbeitet:
E
eclipso
Guest
Komisch das du auf solche Marketingbegriffe wie Giga reinfällst. Der RT Core braucht allein bis zu 10ms, da kannst du noch so viele verbauen. Das Ding ist im Vergleich im zu anderer Hardware fast zu eine lahme Ente. Es ist wie immer, solange niemand mit einer allgemeingültigen Methode kommt die den Mainstream pusht, wird Nv ihr prorietäres Modell fahren und sich um den Rest einen Kericht scheren. Anscheinend ist dir nicht mal klar wie groß die Chips ausfallen müssten, wenn man die RT Core Menge deutlich erhöht. Sie würden immer wieder 20-30% der Diefläche einnehmen, obwohl man sie nicht wirklich braucht. Es geht wie immer darum das sie da sind und man eine Daseinberechtigung für sie sucht, sie sich förmlich einredet und es nur dieses Modell gibt, wozu ist jedem klar. Um allgemeine bzw. universelle Standards zu verhindern und den Markt für Zeiträume ohne Konkurrenztechnologie deutlicher auf Nv zu fokussieren. War unter dx11 versus dx12 genau das Gleiche. Bis man immer wieder klein bei geben muss, dafür von der Community aber noch gelobt wird. Ihr kauft halt gerne neu. Sei's drum...
Da muss man nicht drauf reinfallen. Du kannst eine einfache randomisierte dispatch- Routine im visual Studio anstoßen und schauen, wieviele rays das Ding pro Sekunde verschiessen kann.
Wie hast Du den Wert erhoben?
Siehe oben- Wie hast Du gemessen, so dass ich es nachstellen kann und den fehlerhaften Wert prüfen kann?
Geht das wieder los.... Die Hardware der Grafikkarten aller Hersteller ist proprietär.
Wofür die RT- Core Menge erhöhen? Ich habe doch gerade vorhin ausgeführt, dass nicht die RT- Cores den Flaschenhals darstellen.
Es kommt auf die Integration an.
Du versuchst hier Dinge zu leugnen, die in der Praxis aber nunmal schon x- Fach ihre Funktionalität unter Beweis gestellt haben.
Wenn es so wäre, wie Du sagst, dann wundert es mich, warum man erst jetzt RTRT in Spielen sieht. Und wenn es diese fixed function Beschleunigung nicht braucht, wundert es mich, dass Karten ohne diese eklatant in ihrer Leistung einbrechen. Und wir reden hier von Faktoren an Leistung...
Es muss ja nicht die Hardwarelösung von NV sein. Daran hält ja keiner fest (nichtmal NV selbst, wenn man sich deren GDC Ausführungen so ansieht).
NV hat ja auch angekündigt mit Ampere große Änderungen an deren RT Engine/Pipeline durchzuführen. Es war nun einfach mal eine erste Implementation, die aber schon erstaunlich gut funktioniert hat.
Wobei auch hier die Maxime für einen Hybriden gültig bleibt. Nur ein Strahl, der nicht verschossen werden muss, ist ein guter Strahl.
Dagegen spricht der open source Ansatz einiger NV- Technologien (siehe QTR2 Raytraced, wo sie gute Einblicke in die Trickkiste gewähren) und deren Bemühungen in Sachen DXR und Vulkan RT, welche eben eine einheitliche Schnittstelle für alle Hardwarehersteller darstellt.
Da hat sich die letzten Monate eher AMD verschlossen gezeigt...
Wollten sie proprietär sein, würden sie ihr eigenes Ding fahren (RTX only) und nicht Programmierteams unterstützen, die herstellerunabhängige DXR Lösungen zur Verfügung stellen (z.B. für Unreal und Unity), welche dann von AMD mit deren Ansatz schön kostenlos genutzt werden können.
Du leugnest halt (aus welchem Grund auch immer), dass man mit vor RTX erhältlicher Hardware RTRT einfach mangels Performance nicht sinnvoll nutzen konnte.
Die RT Cores bzw. die Einheiten im Texturprozessor, die gewisse wiederkehrende und zeitintensive Funktionen von RT beschleunigen, sind nunmal aktuell einfach eine Voraussetzung dafür, dass es überhaupt in annehmbarer Performance funktioniert.
Bist Du auch einer dieser User, die meinen, dass die RT Cores bzw. deren Funktion nur Fake ist und alles in der gleichen Performance per Compute hätte dargestellt werden können?
Hast Du überhaupt schonmal einen einzigen Performance debug Verlauf wahlweise einer großen Engine oder des Grafikkartenherstellers in Sachen RT analysiert?
Ich verrate es Dir: Hast Du nicht. Sonst würdest Du so Manches, was Du hier schreibst nämlich einfach nicht behaupten.
LG
Zero
Zuletzt bearbeitet:
E
eclipso
Guest
Ich schmunzle wie höflich du doch bleibst, wenn man deine Lieblingsfirma mal hinterfragt!
Ich habe included FATBVH schon ein globales Intersect Scene Any über FR verschossen, da hat Nv noch über seine RT Cores gegrübelt. Völlig ohne einen RT Cores. Herr der Ringe wurde nicht mit Nv gerendert!
Für dieses Forum bist du in der Tat besonders wertvoll. Dann mal viel Spaß.
Zuletzt bearbeitet von einem Moderator:
Ich mache mir nichts aus Firmen. Das sind andere, die dafür "Gefühle" aufbringen können. Werde ich nie verstehen...
Und es würde vieles einfacher machen, wenn sich alle anderen ein Beispiel daran nehmen würden.
"Fan" von Firmen oder Marken zu sein, die aus kommerziellen Interessen Schaltungen auf den Markt werfen.
Wie schräg ist das denn?
Jetzt machst Du schon wieder ein neues Fass auf, was NICHTS mit der ursprünglichen Fragestellung zu tun hat.
Fällt es Dir wirklich so schwer, einfach mal bei einem Thema zu bleiben und einfachste Fragen zu beantworten?
Was spricht denn dagegen, dass Du das schon getan hast? Was hat es mit dem Thema zu tun?
Ich will von Dir wissen, wie Du auf die 10ms kommst und darauf, dass die RT Cores lahme Enten wären.
Bring einen Beleg oder nimm es zurück.
Vor allem aber- Beantworte endlich mal nur eine Frage, die man Dir stellt.
Und nochmal ein neues Fass... Wieder komplett ab vom Thema.
eclipso, so wird das nichts. Wenn Du nicht einen Milimeter auf jeweils das eingehst, was hier überhaupt Thema ist und was geschrieben wird und Du zeitgleich auf keine einfache Frage, die man Dir im Zusammenhang einer Diskussion stellst antworten willst, dann frage ich mich schon, warum Du Dich überhaupt in Foren rumtreibst... Selbstgespräche, mit welchen Du Dein Ego streichelst?
Provokation? Brandbeschleunigung? Falschinformationen verbreiten?
An einer technischen Auseinandersetzung ist Dir (zum wiederholten Male bewiesen) nicht gelegen.
Ein Forum ist keine Einrichtung, wo man Twittermäßig gerade seine aktuelle Gemütslage mitteilt.
Da lesen Leute mit, die Information aus den Threads ziehen wollen.
Zuletzt bearbeitet:
G
gaussmath
Guest
An dem Code wäre ich interessiert.
E
eclipso
Guest
Dann halte dich doch bitte mal selbst daran!
Nochmal und zum mitlesen für dich: RT spezifische Worksloads erfordern einen Process Sheduler und weil AMD genau diesen nicht brauchen und umgehen möchten, führen sie die Engine programmierbar aus, dass bedeutet fixed function Zugriffe (Intersection) sind nur erforderlich, wenn die Rechenergebnisse von denen, die durch die Shader ermittelten abweichen, ansonsten bleibt das DING frei programmierbar und kann umgangen werden. Der Texturverarbeitungspfad ist dabei viel einfacher aufgebaut, als ein RT Core. Fixed function braucht es also nur dann, wenn der Pufferinhalt überschrieben werden muss. Das spart mehr Zeit, als den Baum ständig komplett zu durchlaufen und auf ein Rechenergebnis zu warten. Diese "Zustandsmaschine" im Texturprozessor vergleicht also spezifische Daten (vermutl. der ersten Ebene). Ähnlich hat man es früher auf CPUs berechnet. Die Raytracer werden durch einen Shader erstellt und an den Texturprozessor übergeben, weil das anders als klassische Hardwarelösungen, wie Nv's RT Core, Platz spart.
Was du also auf Nv Hardware umherspielst und ob du dort irgendwelche Workloads oder Raymengen unter einer Engine analysieren willst, ist mir völlig Schnuppe. Weil das völlig anders abläuft. AMDs Texturprozessorpfad ist also KEIN spezifisch proprietäer Ansatz wie Nv's RT Core, der zwingend für eine Traverse durchlaufen wird.
Was bitte willst du hier aus Threads für Informationen ziehen? Das Niveau hier ist unterirdisch. Ich habe mich hier nur angemeldet, um das, was du hier verzapfst richtig zu stellen.
HardwareHighlander
Gesperrt
Schlicht und ergreifend völliger Unfug.
Deine Beiträge sind einfach größenteil nur reine fangetriebene Falschinformation, rein aus dem Grund, weil AMD noch keine Umsetzung auf dem Markt hat.
Proprietär mit Hardware in den Mund zu nehmen, tut schon weh.
Interessanterweise kann man aus den Posts von Gaussmath und ZeroZerp mehr Informationen ziehen als aus deinen.
Soso- Wieso dann überhaupt eine ray intersection engine, wenn die "Rechenergebnisse?" lt. Deiner Aussage von den Shadern ermittelt werden?
Woher stammen denn die "Rechenergebnisse" (welche Rechenergebnisse?), die der Shader mit dem "Pufferinhalt" (wie wird der generiert und was beinhaltet dieser an Information?) abgleicht?
Klar- Weil das so ein wahnsinnig offener Ansatz ist, legt AMD ein Patent drauf...
Das machen die sicher, um es dann Gott und der Welt kostenlos zur Verfügung zu stellen.
Zur Definition:
Bau mal eine AMD Grafikarte per reverse Engineering nach und vertreib sie. Dann wirst Du eine bessere Idee davon erhalten, wie proprietär das Ganze ist, wenn Du kurz darauf gesiebte Luft atmest.
Kannst ja auch einfach mal versuchen eine Grafikkarte zu entwickeln und nur die ray intersection engine im Texturprozessor bzw. deren Funktionsweise zu kopieren. Kommt dann aufs Gleiche raus.
Zudem- Du bist der einzige, der hier laufend versucht das Niveau runterzuziehen. Alle anderen bemühen sich um eine sachliche Diskussion mit Dir, auf die Du aber offensichtlich garkeinen Wert legst...
Das unterstreichst Du durch einen Dauerignore der Aussagen, Nichtbeantwortung von Rückfragen und Deinem unfreundlichen und überheblichen Umgangston.
Es hat streckenweise wirklich den Anschein, als ob Du hier einfach irgendeine Ideologie durchdrücken willst.
Wir kommen so garnicht auf eine technisch oder fachlich tiefgreifende Diskussion, weil sich die Diskussion schon beim Kratzen an der Oberfläche
komplett in nicht Themenerelavanten Dingen verliert.
Wenn man sich schon im Groben, Ganzen nicht miteinander unterhalten kann, was würden dann technisch tiefgreifende Diskussionen erst für ein Chaos in das Forum bringen?
Ich gehe schon aus, dass Du weisst, was Du da schreibst. Ist es ja zum Teil auch kein Quatsch. Vielleicht sinds auch sprachliche Hürden. Ich weiss es nicht...
Eigentlich schade...
LG
Zero
Zuletzt bearbeitet:
E
eclipso
Guest
Aua...
Wikipedia schrieb:
Man Schaffe...
Was ihr grundlegend vergesst, dass wir über hybrides Raytracingverfahren schreiben und dessen Ausführungsgeschwindigkeit von der Rasterizieungsleistung abhängt, weil als Primärstrahl, "Raster-Renderpasses" als Ausgangspunkt für Strahlen genutzt werden, die pixelgetreue Mitte der Kameraperspektive. Das geht in hybriden Verfahren einfach nicht anders.
Warum Intersect, warum Raygeneration? Weil selbst unter der dxr Raytracingpipeline solche Shader ausgeführt werden (müssen).
Ja, wenn einem grundlegend etwas fehlt, braucht man sich erst gar nicht unterhalten. Wenn man heute von fixed function oder fixed function Einheiten spricht, geht es nicht mehr um die expliziete Bindung an eine Ausführungseinheit in Hardware (bis dx7 oder opengl), dass ist in den seltenden Fällen so. Heute werden Prozesse mit festen Funktionen von Shadern emuliert und heute man kann sie, aufgrund des vorhanden Kompatibilitätsprofils auch nicht mehr ohne Shader ausführen. Festfunktionskonzepte fehlen dem Coreprofil der meisten Hardware deshalb, auch wenn Hersteller es immer wieder ansprechen (oder deren Marketingheinis, die sowieso keine Ahnung haben und nicht mal Whitepaper lesen). Sie meinen damit nur, dass dem Prozess bestimmte Hardwareressourcen zugeordent werden müssen, wie es auch bei einem hybriden Raytracingmodell der Fall ist. Die Funktionspipeline hängt dabei im wesentlichen von den Berechnungen in der Texturumgebung ab, sonst würde auch RTRT nicht funktionieren.
Ich belass es dabei, weil wir meilenweit auseinander sind und es tatsächlich das Forenklima stört.
Mit RTRT, RT Core oder RTX ist das Allheilmittel, kommt man trotzdem nicht weit. Derzeit besteht es aus einem Modell, dass auf ein Rasterizierungsverfahren aufsetzt und man deshalb auch genausoviel Rasterizierungsleistung braucht. Das hat Nv meiner Meinung nach unterschätzt. Man kann fehlende Rechenpower nicht technologisch ersetzen, dass wird nie funktionieren. Davon sind wir noch meilenweit entfernt. Man kann es nur kaschieren, was sie seit Erscheinen von Turing auch machen. Hier was weg, dort was hin usw. usf. gefrickelt das es läuft.
Zuletzt bearbeitet von einem Moderator:
HardwareHighlander
Gesperrt
Na, das meine ich doch. Hardware ist bei AMD und Nvidia proprietär und das trifft auf Nvidias Ansatz mit RT Cores zu wie genauso auf AMD´s Lösungsansatz, melden ja das Patent nicht umsonst an.
Du verdrehst hingegen nun schon zum drölften Mal den Kontext und biegst es jetzt wieder um 180 Grad herum.
Der war billig und wieder x Nebenschauplätze und neue Themenfelder aufmachen.
AMDs Lösung ist nicht "offen" sondern genauso proprietär wie nVidias.
Was am Ende besser ist, wird man dann sehen.
Guter Witz.
Zuletzt bearbeitet:
Genau so ist es... oder auch nicht, da ich einige Dinge, die Du schreibst ebenso mittragen würde.
Nicht wieder alles in einen Topf werfen.
RTRT=Realtime raytracing ->Wieso soll man damit nicht weit kommen, wenn es doch grafisch unbestritten der heilige Gral ist?
RT Core=Wie Du richtig schreibst sind dedizierte in Hardware gegossene Einheiten/Schaltungen zur Beschleunigung fest vorgegebener Berechnungen (diese dafür sehr schnell) oftmals eine Zwischenlösung, bis die Rechenleistung oder Funktionserweiterungen von unified Einheiten ausreicht, die dazu dann auch noch deutlich flexibler einzusetzen sind.
RTX = Markenbezeichnung einer Generation von Grafikkarten / Teils auch Bezeichnung eines Featuresets
Der Begriff ist also generisch und unter RTX kann unter Umständen schon durch den Nachfolger von Turing ein anderes/optimiertes Verfahren diverser Features zum Einsatz kommen
Hat also auch letztenendes nichts mit "nicht weiterkommen" zu tun.
Genau so ist es.
Da bin ich mir nicht so sicher. Ich denke, die wussten sehr genau, dass man einen steinigen Weg mit dem Hybrid- Verfahren vor sich haben würde und dass es am Anfang nur für "kleine" Lösungen reichen wird (die allerdings schon deutlich besser aussehen, als die Raster- Tricks).
Den Satz verstehe ich nicht, da Rechenpower derzeit ja rein technologisch überhaupt herbeigeführt wird. Somit ist letztendlich der einzige Weg fehlende Rechenpower mit besserer Technologie zu ersetzen.
Genau- Durch diverse Griffe in die Trickkiste funktioniert das annehmbar. Angenommen sie machen bezüglich der RTRT Leistung tatsächlich eine 50%ige Steigerung wahr, dann wären die Folgegenerationen inkl. noch eines Tricks (DLSS- auch die Tensor- Core Zahl wird vermutlich steigen und dadurch die DLSS Qualität) schon schneller, als es die Touring Generation ohne RTRT Einsatz wäre.
Sooo weit sind wir also garnicht davon entfernt.
Dass man RTRT Qualitativ bezüglich der Leistung noch vielfach potenzieren müsste, dass alles in hohen Auflösungen und top- Qualität läuft (auch die unangenehmen Refractions, rauhe Oberflächen bzw. diffuse Spiegelungen, multibounce) sollte jedem klar sein, der sich mit der Materie beschäftigt.
Ja- Wie es in Sachen Rasterisierung halt auch von Anfang an lief....
Kann man jetzt noch schön sehen, wenn man z.B. mittels Helix oder Migoto mal die einzelnen Shader von modernen Titeln dumpt und analysiert.
Da werden oftmals sogar noch billigste 2D Effekte nachträglich in die Projektionsmatrix "geklebt".
Die Frage ist, ob es wirklich so schlau ist, bei den "alten" Verfahren und Tricks zu bleiben, oder ob man nicht doch jetzt schon Techniken des technologischen Ziels bei Computergrafik einfliessen lässt, die gewisse Dinge besser machen. Raytraced AO zum Beispiel YouTube oder Schatten von point lights u.a. mit visibility sampling/buffer (area lights wären wieder unangenehmer), die noch dazu kaum auf die Performance gehen, aber die Szenerie deutlich aufwerten.
Diese "ganz oder garnicht"- Einstellung, die einige beim Thema RTRT hegen, verstehe ich überhaupt nicht, da sie entgegen aller bis jetzt langjährig entwickelten Technologien steht.
Soll man Raytracing wieder begraben und noch mehr fehlerhaftes Rasterblingbling zum Vertuschen der Unzulänglichkeiten integrieren? Macht es das dann besser?
Ich denke nicht. Es wird in meinen Augen auf lange Zeit hinweg beim Hybriden bleiben, weil der Rasterbasierte Ansatz ziemlich ausgeforscht ist und manche Dinge einfach effektiver rechnet, als RT. Das gilt aber genauso umgekehrt....
LG
Zero
Zuletzt bearbeitet:
E
eclipso
Guest
Du weißt aber schon das Nv die Intersectionsshader gar nicht einsetzt und das es sogar Teile in der RTX-API gibt, welche bisher nicht zum Einsatz kommen weil sie für speziellere Anwendungsfälle gedacht sind? Du schreibst ja auch, du hättest Engines bzgl. der Raycast-Menge analysiert, aber dem entgegen steht, dass der Aufbau der Beschleunigungsdatenstruktur und deren Traversierung, also die Hauptteile von RTX für den Benutzer nicht einsehbar sind und nur über undurchsichtige Einstellungen veränderbar sind, die nicht erschließen welchem Einsatzzweck sie schlußendlich dienen! Es ist also alles beim alten, dediziert und proprietär mit Blackboxcharakter (wie Epic das schön unter Hairworks beschrieb). Genau das versuchts du vehement auf AMDs Patent zu übertragen. Hast du mit Vulkan überhaupt schon mal eine Ray Tracing Szene erstellt? Ich glaube das nicht, denn dann wüsstest du warum es die Shadertypen gibt und was sie in ihrem Patent ansprechen wollen.
Aber egal, ich glaube du bist nur hier um RTX zu promoten, schrieb ich schon in meinem ersten Satz. Muss jeder wissen was er will und macht. Den Callable Shader (Call) nutzen sie übrigens auch nicht.
Direct3D 12 Raytracing - Win32 apps | Microsoft Docs
Aber egal, ich glaube du bist nur hier um RTX zu promoten, schrieb ich schon in meinem ersten Satz. Muss jeder wissen was er will und macht. Den Callable Shader (Call) nutzen sie übrigens auch nicht.
Direct3D 12 Raytracing - Win32 apps | Microsoft Docs
Zuletzt bearbeitet von einem Moderator:
E
eclipso
Guest
Ja guter Witz du schreibst dir schon einen Haufen Schrott zusammen. Wer hier was um 180° dreht, einfach mal lesen was du schreibst! Das hier ist absolut nicht zweideutig!
Und das nächste Ding, Vulkan ist nicht offen? O.k. wusste ich noch nicht und nun nochmal das Patent aus 2017 lesen! Vulkan kann man sich sogar so hinbiegen wie man will! Einfach mal PICA PICA anschmeissen und staunen (das kriegst sogar du hin). Aber wem schreibe ich das...
Daher, vergebene Mühe!
Ja und jetzt?
Nicht Engines- Ich habe mittels Visual Studio ein einfaches Tool generiert, welches einmal mit einfacher Beschleunigungs- und Subbschleunigungsstruktur ein Dreieck befeuert ohne anschliessend die Daten darzustellen und einmal gibts von Microsoft selbst eine Source mit Demo, die in einem geometrisch einfachen Szenario die mögliche Raymenge im Praxisszenario, also mit Auswertung und Darstellung ermittelt.
Ab 4K landen wir dann bei den 10GRays/Sek. ohne Darstellung/Shader bei etwa 14GRays/Sek. Somit hält nvidia seine Aussagen ein, auch wenn diese Werte aus den uns bekannten Gründen in shaderintensiven AAA Produktionen nie anliegen werden.
Deshalb auch mein Hinweis, dass hier die in Deinen Augen "lahmen" RT- Cores in der Praxis derzeit nicht die Bremse sind.
In der Turing Nachfolgegeneration müssten sie letzendlich zumindest bei den großen Karten die RT- Cores garnicht erhöhen. Das werden sie aber aus Marketingtechnischen Gründen trotzdem tun.
Ja- Man sieht nicht en Detail, was nvidia in der Blackbox macht. Als Programmierer und Softwareentwickler ist mir das aber auch herzlich egal, solange das Endergebnis und vor allem die Geschwindigkeit stimmt und ich entsprechende Operationen weitestgehend Async setzen kann.
Da hast Du mich falsch verstanden. Ich schreibe nicht, dass AMDs Ansatz intransparent ist, ich schreibe lediglich, dass er hardware- und durch dedizierte Schaltungen beschleunigt und proprietät ist. Wieso sonst ein Patent und kein "offener" Ansatz?
Ich habs mir kurz angesehen. Das Prinip bleibt letztendlich überall das Gleiche.
Was verstehst Du unter "die Shadertypen"? Der Ausdruck ist vieldeutig.
Und Du versuchst mit aller Gewalt AMD einen wahnsinnig freien und der Allgemeinheit "wohltätigen" Weg anzudichten, der alles besser macht. Nur missachtest Du dabei, dass "besser machen" im Endergebnis nur daran gemessen wird, welche der Lösungen letztendlich leistungsfähiger ist, bzw. die Aufgaben schneller erledigt.
Der Rest ist netter Tech- Talk für Nerds, die sich aufgrund von Microspezifikationen einen r....erholen können.
Hättest Du meinen Text oben aufmerksam durchgelesen wüsstest Du, dass das BS ist. Aber nochmal für Dich- Ich bin Befürworter des hybriden RTRT- Ansatzes bzw. in letzter Instanz dann path tracing, da er einfach weitere einfache Toolsets bietet, Problemstellungen besser lösen zu können, als es bisher der Fall ist.
Der Namensaufkleber, der auf der Grafikkarte klebt, könnte mir nicht egaler sein, da ich durch alle Hersteller in Teilen meine Brötchen verdiene.
Ich betone nochmal- Es ist mir unbegreiflich, welchem Markenwahn hier viele inzwischen verfallen sind.
Fechtet Ihr nur Eure Kleinkriege diesbezüglich aus, aber verschont mich damit....
Siehe oben- Das Ergebnis ist entscheidend.
Wenn man dem "Munkeln" um den Turing- Nachfolger glauben schenken darf, wird die "Blackbox" aufgehellt und flexibilisiert. Man wird sehen, was man bekommt.
Da wir in der Firma weder Samples von einer entsprechenden nvidia Nachfolgeggeneration, noch ein Sample einer funktionierenden RTRT- Fähigen Hardware seitens AMD, noch ein Devkit der neuen Konsolen vorliegen haben, kann man hier vortrefflich fabulieren, aber keine festen Ergebnisse und Bewertungen treffen (wie Du es tust).
Hast Du schon Zugriff drauf? Wenn ja, dann sind auch Deine Aussagen pure Spekulation. Haste ja selbst schon angemerkt, dass noch nicht öffentlich bekannt ist, mit welchem Ansatz AMD in der Praxis tatsächlich raus kommt.
Ansonsten betreiben wir hier die letzten Seiten nichts weiter als "Definitionsklauberei".
p.S. So wie Du mir vorwirfst vermeintlich nvidias Lösung promoten zu wollen, könnte man meinen, dass Du aus der Marketing- Abteilung bzw. der selbsternannten White- Knight Abteilung von AMD stammst....
Insofern gehe ich da mit HardwareHighlander konform, dass Du frieden geben wirst, wenn AMD mit seiner hoffentlich leistungsfähigen RTRT- Lösung auf den Markt kommt (Intel wird Dir wiederum nicht passen).
Dann müssen wir uns auch nicht mehr unterhalten, wer hier wie irgendwelche Grafik APIs bedienen will...
LG
Zero
Zuletzt bearbeitet:
H
hks1981
Guest
Jetzt mal ehrlich ihr 3 seid ihr dann mal fertig? Das hier jeder versucht seinen Standpunkt als richtig zu stellen und nur ich habe recht nervt! Tauscht euch doch über PN aus oder schickt euch die Telefonnummern und diskutiert es bei einem Kaffee gemeinsam aus aber sorry das hier ist nur noch OT und Spam und hat mit dem Thema des Threads nicht mehr gemeinsam.
Es gibt gewisse Kandidaten, die PNs (wohl aus einer gewissen Vorahnung) deaktiviert haben. BraveNeo, Olletsag, Gastello und jetzt halt unter dem Nick eclipso hat offenbar kein Interesse, dass man sich direkt austauscht.
Und in Teilbereichen hat das "Gelaber" von uns dann eben doch was mit dem Thema zu tun- Da viele Dinge, die hier angesprochen werden eben auch für Intels Xe Gültigkeit besitzen. Ich will ja eben die ganze Zeit weg von dieser müßigen Hersteller- Fanboy- Diskussion "von dem ist alles schlecht" und von "jenem alles gut".
Und wie Du auch sehen kannst, nähert man sich in den letzten Posts ein wenig an.
Die technischen Ansätze und die Grundvoraussetzungen unter welchen gewisse Dinge geschehen, sind für alle Hersteller gleich. Auch für die Intel Xe.
Somit betrifft hier vieles, was durchgekaut wird, auch diesen Grafikkartentyp. Es geht in der News ja inhaltlich eben auch um Raytracing- Support. Da ist die Diskussion meines Erachtens erlaubt, wie das die Konkurrenten so regeln und worin sich deren Ansätze unterscheiden.
Und so mühsam und nervig es ist. Es ist auch wichtig, was die Nutzer in diesem Zusammenhang zu lesen bekommen. Denn gerade in Sachen Realtime- Raytracing werden gebetsmühlenartig immer wieder die gleichen nicht den Tatsachen entsprechenden Stammtischparolen ausgepackt.
Es sollte im Interesse von allen sein, dass hier mal drüber gesprochen wird. Ich wenns sehr langweilig wird, je weiter man in Richtung Technischem "Geplänkel" vordringt.
Auch da versuche ich ja die Diskussion immer davon wegzulenken und das wichtige Gesamtbild und den Endeffekt für den User in den Vordergrund zu rücken.
Nur gibt es hier eben Personen, die anderer Meinung sind und die sich wohl am liebsten noch in Assemblercode suhlen wollen würden, um ihr Statement zu untermauern.
Aber das sind nur meine "2 cents". Generell bin ich aber voll bei Dir, dass die Art und Weise der Diskussion hier niemanden weiterbringt.
Die dauerhaften gegenseitigen Unterstellungen hiervon und davon keine Ahnung zu haben, sind ganz schlechter Stil (auch von mir, auch wenn ich mich bemühe es so gering wie möglich zu halten),
hat man im Grunde genommen doch keine Ahnung, womit sich das Gegenüber so beschäftigt und welcher Wissensstand vorhanden ist.
Jede Aussage, die nicht ins eigene Weltbild passt, wird in das Reich der Ahnunglosigkeit verschoben. Das Totschalgargument und das Ende einer jeden sinnvollen Diskussion.
Naja- Dann lassen wir den Thread mal in Frieden ruhen....
LG
Zero
Zuletzt bearbeitet:
E
eclipso
Guest
Du bist echt lustig.
Dir ist schon klar das es unter RTX treiberausgeführte fixed functions gibt und frei programmierbare, die man über APIs ausführt, oder? Es ist völlig unsinnig einen Shadertyp nicht parallel auszuführen und die Traverse oder das Intercest dann mittels Treiber erneut über den RT Cores laufen zu lassen, dafür 1000ende Zeilen Code zusätzlich hinnehmen zu müssen, obwohl das gar nicht notwendig wäre? Ehrlich das ist völlig schwachsinnig und Microsoft führt aus, dass alles ab SP 6.3 DXR unterstützt und die Shadertypen waren von Anfang an dabei!
Du traversierst also die Beschleunigungsstructur über den Treiber per RT Core, obwohl es dafür einen Ray Gen Shader gibt und lässt diese Traverse dann nochmal durch den RT Core laufen, obwohl es einen Intersect Shader gibt, die ich in der Pipeline fast zu parallel ausführen könnte? Dann stellst du dich hin und behauptest AMD macht es genauso oder würde das anhand einer Idee genauso tun (in Zukunft)?
Geht es also eher darum, dass Nv die Kontrolle behält und mit ihrem Treiber unter dx12 genug cheaten können, damit deren Katze nicht in den Brunnen fällt? Fehlt ihnen etwas, wie schon unter Maxwell und Pascal der Fall war und bis sie es gelöst haben, verschleiern und so tun als wäre nur ihre Lösung die beste Lösung?
Du weißt schon das Nv sich vor allem beim Kauf von Mental Ray im Thema Raytracing eingekauft hat (wie immer übrigens von denen kommt selten was tiefgreifendes, was sie selbst entwickelt hätten) - (ist sogar 'ne deutsche Firma die vorher viel mit ATI und den Studios zusammenarbeitete), um dann ein Projekt anzustossen, dass dedizierte Einheiten in einem Raytracinghybridverfahren favorisiert, obwohl das DXR oder das dazugehörige Shaderprotokoll so nicht unbedingt vorgibt? Du stellst dich dann hin und behauptest das sei die beste Lösung?
Was soll das mit gastello, Braveneo und wen noch zu tun haben? Die waren wahrscheinlich nur genervt, weil man bei dem Thema hier auf Granit beißt und dir muss klar sein, dass jeder der Nv zeitweise programmiert, eine NDA unterschreibt die nach Beendigung der "Geschäftsverhältnisse" mit denen noch 5 Jahre im Nachgang zur Verschwiegenheit verpflichtet. Etwas offen auszusprechen wie: "Nv ist 'ne Blackboxfirma" kann sich nur Epic leisten, weil die das von ihrer Marktmacht her einfach tun.
Du stellst also Fragen, die dir niemand beantworten kann und behauptest dann, dir würde ausgewichen. Muss es ja oder?
Abschließend kannst du dir gerne ansehen, was unter RTX frei programmiert werden kann und was nicht:
frei
Ray Gen (nicht genutzt)
Any Hit
Intersection (nicht genutzt)
Miss
Closet Hit
nicht frei
Accleration (Nv)
Structure (Nv)
Traversal (Nv)
Du hast also auf wesentliche Funktionen keinen Zugriff und das dir Nv ihren Treiber inklusive daran gebundene Funktionen offenlegt, glaubst du nur selbst. Wenn du also etwas über RTX in Erfahrung bringen willst, arbeite daran. Genau solche Informationen würde für eine große Anzahl an Lesern auch wichtig sein.
Falls du etwas über Programmierung generell wissen willst, ist PCGH nicht das richtige Umfeld, sondern eher 3dcenter oder beyond3d, inclusive der Tutorials die über Devcenter bereitgestellt werden. Da kannst du Entwickler direkt anschreiben und sie antworten zumeist auch.
Zuletzt bearbeitet von einem Moderator:
Du stehst also unter NDA?
Ansonsten:
Dieses ständige Neueröffnen von Themen und reden um den heißen Brei ist sowieso langsam langweilig...
Da hat hks1981 schon recht.
