Warum keine TBDR?

[Banshee18]

Warum sind eigentlich alle aktuellen Chips Immediate-Renderer? Sind diese in der zwischenzeit so effektiv, dass sich TBDR nicht mehr lohnen? Ich glaube es kaum. Hat man einfach Angst vor einem Umstieg? Fehlt das Know How? Diese Frage stelle ich mir schon lange.
Besteht eine Chance, dass zumindest die übernächste Chipgeneration TBDRs sind?

mfg

Banshee

[Hamster]

hmm ist es nicht so, daß die treiber der ihvs mittlerweile relativ gut overdraw vermeiden können, und so TBDR gar nicht mehr von nöten ist, bzw kaum leistungssteigerung bringt?

[Coda]

Mit Hyper-Z und Konsorten hat man ja schon viele Vorteile eines TBDR eingebaut.

[Banshee18]

hmm ist es nicht so, daß die treiber der ihvs mittlerweile relativ gut overdraw vermeiden können, und so TBDR gar nicht mehr von nöten ist, bzw kaum leistungssteigerung bringt?

Genau das will ich ja wissen. =)

Mit Hyper-Z und Konsorten hat man ja schon viele Vorteile eines TBDR eingebaut.

Viele, aber bei weitem nicht alle. Ich denke, dass ein TBDR doch um einiges effektiver ist.

[Coda]

Mitnichten, du must ja auch erstmal rausfinden welche Polygone in einem Tile zu rendern sind und welche nicht etc.

[Banshee18]

Wieviel Prozent könnte man dann in etwa noch durchschnittlich rausholen?

[aths]

Wieviel Prozent könnte man dann in etwa noch durchschnittlich rausholen?Einiges. TBDR haben dafür an anderer Stelle Nachteile: Statt ggf. große Dreiecke rendern zu können, müssen in kürzerer Zeit mehrere Dreiecke (bzw ihre Teile davon) in die Pipes. Die Texturen und Shader müssen öfters umgeschaltet werden. Kein Ding der Unmöglichkeit, aber das kann je nach Konstruktion durchaus neue Ineffizienz nachsich ziehen. Ein gut konstruierter TBDR wäre wohl trotzdem in den meisten Situationen schneller.

[Banshee18]

Ich zitiere mich einfach mal selbst:
Hat man einfach Angst vor einem Umstieg? Fehlt das Know How?
Wird man irgendwann mal TBDRs von den beiden großen IHVs zu Gesicht bekommen?

[mapel110]

Ich zitiere mich einfach mal selbst:

Wird man irgendwann mal TBDRs von den beiden großen IHVs zu Gesicht bekommen?

Höchst unwahrscheinlich. Ich glaube, darauf muss man solange warten bis ein anderer Hersteller einen TBDR bringt, der den Grossen das fürchten lernt und diese keinen anderen Ausweg sehen, als die selbe Technik anzuwenden.
Sowas ähnliches sieht man derzeit schön im CPU-Sektor. :)

[aths]

Grossen Was hast du nur gegen das ß?

Ich zitiere mich einfach mal selbst:

Wird man irgendwann mal TBDRs von den beiden großen IHVs zu Gesicht bekommen?Theoretisch verfügt NV über die Technik. "Irgendwann" ist natürlich alles möglich. Man darf aber nicht übersehen, dass viele Wege nach Rom führen. NV hat offenbar große Anstrengungen unternommen, IMR möglichst schnell zu machen. Würden die einen TBDR bauen, wäre der vom Effizienz-Grad her nicht so hochoptimiert wie ein IMR, den sie entwickeln könnten.

Mit SM3 steht eine weitere effizienzsteigernde Technik zur Verfügung, welche die Notwendigkeit (so man sie sehen will) von TBDR ein weiteres mal hinausschiebt.

[Demirug]

Theoretisch verfügt NV über die Technik. "Irgendwann" ist natürlich alles möglich. Man darf aber nicht übersehen, dass viele Wege nach Rom führen.

Nicht nur Theoretisch würde ich sagen. Man müsste sich aber mal mit Ming Benjamin Zhu unterhalten.

[robbitop]

um einen TBDR zu bauen, muss man bei vielen Dingen "noch mal" von vorn anfangen beim Chipdesign. Und man muss Erfahrungen sammeln, um die Effizienz oben zu halten. Das sollte Jahre kosten und viel Geld. Und da man den Gegner sehr stark im Nacken hat, kann sich niemand dieses Risiko leisten. Es wird IMO wohl beim IMR bleiben.

[Banshee18]

Mit SM3 steht eine weitere effizienzsteigernde Technik zur Verfügung, welche die Notwendigkeit (so man sie sehen will) von TBDR ein weiteres mal hinausschiebt.

Effizienz und somit mehr Leisung kann man imho nie genug haben.
Und da man den Gegner sehr stark im Nacken hat, kann sich niemand dieses Risiko leisten.

[Ironiemodus an]Konkurrenz behindert also den Fortschritt?!? Da wünscht man sich ja beinahe eine Monopolstellung eines IHVs.[Ironiemodus aus]
Sind TBDR grundsätzlich schwerer zu entwickeln bzw. zu optimieren? Man hätte ja von Anfang an mit TBDR beginnen können. Oder fehlte nur die Idee?

[mrt]

Könnten da nicht auch noch etwaige Patentstreitigkeiten mit spielen.
Es gibt ja doch einige kleine Firmen mit solchen Patenten, die würden sich sicher freuen wenn sie einem der großen IHVs Geld abknöpfen können.

[robbitop]

[Ironiemodus an]Konkurrenz behindert also den Fortschritt?!? Da wünscht man sich ja beinahe eine Monopolstellung eines IHVs.[Ironiemodus aus]
Sind TBDR grundsätzlich schwerer zu entwickeln bzw. zu optimieren? Man hätte ja von Anfang an mit TBDR beginnen können. Oder fehlte nur die Idee?

In gewisser Weise ja. NV40 wird nicht für seinen Fortschritt gelobt. R200 wurde es nicht. R420 und NV25 schon. Konkurrenz lässt risikobereitschaft sinken.

Ein TBDR würde viieeel Zeit kosten und großes Risiko.
Man hätte auch von anfang an zu NV3 Zeiten diesen Weg einschlagen können..tat es aber nicht. Man wählte den populären weg.

[aths]

Effizienz und somit mehr Leisung kann man imho nie genug haben.


[Ironiemodus an]Konkurrenz behindert also den Fortschritt?!? Da wünscht man sich ja beinahe eine Monopolstellung eines IHVs.[Ironiemodus aus]
Sind TBDR grundsätzlich schwerer zu entwickeln bzw. zu optimieren? Man hätte ja von Anfang an mit TBDR beginnen können. Oder fehlte nur die Idee?Nvidia und 3dfx, die ja heute nur noch Nvidia heißen, kommen von SGI, welche das IMR-Konzept soweit ich weiß (zunächst in den Fachkreisen) populär gemacht haben. Mit wenig Hardware-Aufwand lässt sich damit ein gutes Ergebnis erzielen. Das wurde dann immer weiter verfeinert.

Mehr Leistung kommt auch durch höhere Parallelität und höheren Takt. Man sollte besser als die Konkurrenz sein, aber es besteht kein Zwang, das bestmöglichste zu machen was theoretisch machbar wäre. Wie schon gesagt haben TBDR bezüglich der Effizienz nicht nur Vorteile.

IMR mit Early-Z-Mechanismen profitieren von der ohnehin oft vorgenommenen groben Front-to-back-Sortierung und verschwenden damit weniger Füllrate. Die Z- und Color-Compression schont die Bandbreite. Die 6600 GT ist doch ein gutes Beispiel, was IMRs mit überschaubaren Rohleistungsmerkmalen bringen können. Einer der Gedanken von SM3 ist ja, nur die Shader-Anweisungen auszuführen, die für das Pixel notwendig sind. Letzlich spart das auch "Füllrate". Dank der großzügigen maximalen Shaderlänge und der neuen Register (und der neuen Textur-Operationen) kann man außerdem fast alles singlepass rendern. Spart Bandbreite.

Dank der hohen Z-Füllrate heutiger Karten kann man das CPU-lastige Vorsortieren der Polygone auch sparen, und den Z-Puffer zuerst rendern. Belastet am Ende dann doch wieder CPU und den Vertexshader, drückt aber den Pixelfüllraten-Verschnitt erheblich. So kann man sich durchaus mit IMR-Technik arrangieren.

[Coda]

ohnehin oft vorgenommenen groben front-to-back-SortierungNicht ohnehin, sondern genau aus dem Grund. Sonst würde keiner auf die Idee kommen einfach seine Geometrie zu sortieren (außer für Alpha Blending natürlich)

[robbitop]

Dank der hohen Z-Füllrate heutiger Karten kann man das CPU-lastige Vorsortieren der Polygone auch sparen, und den Z-Puffer zuerst rendern. Belastet am Ende dann doch wieder CPU und den Vertexshader, drückt aber den Pixelfüllraten-Verschnitt erheblich. So kann man sich durchaus mit IMR-Technik arrangieren.

Wenn sich das wirklich so lohnen würde, warum machen NV und ATI das nicht?
Bei S3 funktioniert das IMO nicht so prickelnd.

[Matti@work]

Mit SM3 steht eine weitere effizienzsteigernde Technik zur Verfügung, welche die Notwendigkeit (so man sie sehen will) von TBDR ein weiteres mal hinausschiebt.

SM3 heißt doch Shader-Model-3, oder? Was hat das mit Effizienz-Steigerung zu tun?

[Coda]

Mit SM 3 kann man Instructions im Shader nicht ausführen, die man nicht braucht.

[Matti@work]

...was meinst du? So eine Art Echtzeit-Code-Optimierung oder einfaches Early-Z?

[marco42]

Was hast du nur gegen das ß?


Vielleicht hat er keins auf der Tastatur so wie ich? Workstations wurden frueher zB fast nur mit US layout ausgeliefert. Laesst sich IMHO besser programmieren.

[aths]

Nicht ohnehin, sondern genau aus dem Grund. Sonst würde keiner auf die Idee kommen einfach seine Geometrie zu sortieren (außer für Alpha Blending natürlich)Das wurde vorher auch schon gemacht (Z-Bandbreite.)

[mapel110]

Was hast du nur gegen das ß?

Eigentlich nix, immerhin haste mir das Plenken abgewöhnt. Schon mal ein Teilerfolg. :uup:
Vielleicht hat er keins auf der Tastatur so wie ich? Workstations wurden frueher zB fast nur mit US layout ausgeliefert. Laesst sich IMHO besser programmieren.
Ich hab ne ganz billige Standardtastatur für 10 €. ;(

[aths]

Wenn sich das wirklich so lohnen würde, warum machen NV und ATI das nicht?
Bei S3 funktioniert das IMO nicht so prickelnd.Es lohnt nicht immer. Bei langen, aufwändigen Pixelshader-Programmen steigt die Wahrscheinlichkeit, dass es lohnt. Heutige Spiele sind eh schnell genug, der Rechenaufwand durch neue, komplexere Pixelshader-Effekte kann durch SM3 und EarlyZ gesenkt werden, so dass man weniger zusätzliche Rohleistung braucht als man zunächst vielleicht denken würde. Insofern sollte man auch mal abwarten, was der NV40 denn nun wirklich bringen kann, wenn er vernünftig genutzt wird.

[Coda]

Das wurde vorher auch schon gemacht (Z-Bandbreite.)Ja richtig, aber auch aus dem selben Grund ;)

[Ailuros]

Nicht nur Theoretisch würde ich sagen. Man müsste sich aber mal mit Ming Benjamin Zhu unterhalten.

Keine Ahnung was der Herr zu sagen hat, mir wurde auf jeden Fall auf Anfrage off the record zugefluestert, dass man sich vom Gigapixel IP (GP_LP) weggehalten hat (anstatt AR10 z.B.) weil mein keine Lust fuer Patent-Fuselei hatte.

Ich koennte eigentlich einsehen dass es fuer PC standalone Produkte keine ueberwiegenden Gruende gibt um auf TBDR zu wechseln. Bei kleinen eingebetteten chips aber und ueberhaupt in SoCs mit UMA, haette es auf jeden Fall sehr guten Sinn gemacht.

Sind TBDR grundsätzlich schwerer zu entwickeln bzw. zu optimieren? Man hätte ja von Anfang an mit TBDR beginnen können. Oder fehlte nur die Idee?

Heutzutage wohl nicht mehr. So weit entfernt sind heutzutage TBDRs und IMRs nun auch wieder nicht und ueberhaupt wenn die letzteren einen tiled back buffer haben und eine early-Z optimierte Applikation den Renderungs-Prozess sowieso verzoegert. Die uralte KYRO schwingt womoeglich auch mal in seltenen Faellen in einen quasi "IMR-modus", nur war eben bei der die theoretische Fuellrate verheerend niedrig fuer diese Faelle.

Ein heutiger moderner TBDR haette weder von der Bandbreite noch von der Framebuffer-Groesse Probleme float HDR mit AA zu kombinieren. Im Durchschnitt duerfte der Framebuffer-Verbrauch generell auf die TBDR-Seite schwenken.

[Demirug]

Keine Ahnung was der Herr zu sagen hat, mir wurde auf jeden Fall auf Anfrage off the record zugefluestert, dass man sich vom Gigapixel IP (GP_LP) weggehalten hat (anstatt AR10 z.B.) weil mein keine Lust fuer Patent-Fuselei hatte.

Der Herr ist der DR Spezialist bei nVidia.

[Ailuros]

Der Herr ist der DR Spezialist bei nVidia.

Zhu stammt aus der vorigen Gigapixel bzw. SGI Schmiede? (bin jetzt wirklich zu faul alte whitepapers und Patente auszugraben von damals)

[Demirug]

Zhu stammt aus der vorigen Gigapixel bzw. SGI Schmiede? (bin jetzt wirklich zu faul alte whitepapers und Patente auszugraben von damals)

Keine Ahnung wo er seine Zeit vor nVidia verbracht wird. Er taucht eben nur immer wieder auf wenn es um nVidia und DR geht.

[ram]

Vielleicht hat er keins auf der Tastatur so wie ich? Workstations wurden frueher zB fast nur mit US layout ausgeliefert. Laesst sich IMHO besser programmieren.

Vielleicht ist er Schweizer?