Die Vor- und Nachteile von TBR

[Xmas]

So, auf Thowes Vorschlag eröffne ich hier mal einen neuen Thread...
Es geht hier um die Vor- und Nachteile von Tile-based Rendering, aktuell durch Chips der PowerVR Series 3 vertreten, gegenüber traditionellen Architekturen, auch SGI-Renderer oder Immediate Mode Renderer (IMR) genannt.
Das soll keine Diskussion über alternative Speichertechniken wie RAMBUS, QDR oder eDRAM werden, sondern sich wirklich rein um die Chiparchitektur drehen. Wo seht ihr Probleme und/oder Vorteile von deferred Rendering?
Ich bringe bewusst noch nicht meine eigenen Überlegungen ein, da sonst möglicherweise nur darüber diskutiert wird und andere Ideen unter den Tisch fallen. Erst mal sollten ein paar Argumente von verschiedenen Standpunkten zusammenkommen, bevor die richtige Diskussion anfängt.

[Leonidas]

Der Vorteil von TBR ist der Nachteil :-).


Denn: TBR bringt seine 30% in der Realität - und das war es dann. Es ist ein *einmaliger* Schub. Wenn der Overdraw einmal weg ist, dann ist Feierabend - es geht nicht mehr zu optimieren.


Also: TBR wird nur einen Zwischenstop für den BruteForce Renderer bilden, nach TBR geht es wieder mit BruteForce weiter.


Das soll TBR nicht schälern, auf keinen Fall. Aber TBR ist keine unendliche Technologie, die immer wieder weiter besser wird. Sie bringt einen einmaligen Vorteil. Ist sie einmal integriert und sucht man *danach* nach weiterer Steigerung, helfen wieder nur die alten Rezepte (oder gänzlich neue Architekturen).


Ansonsten sehe ich kaum Nachteile. Letztlich gleicht der K2 von der Architektur außerhalb des TBR dem MX400 (ganz grob) und nicht der GTS, auch wenn die Performance (durch das TBR) GTS-Niveau ist. Dass es bei einer solchen LowCost-Architektur Schwachstellen und Engpässe gibt, ist klar - dies ist bei der MX400 nicht anders. Die meisten der üblichen K2-Schwachstellen sind aber IMHO ein Problem der K2 (siehe Leistungseinbruch bei anisotropischem Filtern), keine Sache von TBR.

[StefanV]

Es gab zu den Anfangszeiten des '3D-Zeitalters' auch noch einen anderen Ansatz der SGI Renderer.

Die Jetzigen haben ja alle eine Pipline, wenn ich mich recht erinnere, dann hatte dieser Chip KEINE Pipline (und bei gleicher Leistung nur halb so viele Transistoren, wie eine NV3(Riva128)).

Mit einem neuen Treiber könnte man diesem Chip einen VS geben.

Leider wurde dieser Chip nicht mehr weiterentwickelt.

[Legolas]

Und wer hat diesen ominösen Chip entwickelt? Würde mich brennend interessieren, weil ich davon noch nix gehört hab. Kannst du vielleicht auch etwas mehr über dieses alternative Konzept für SGI-Renderer sagen, oder weißt du auch nicht mehr?

Zum TBR:

Also ich denke, für Spiele ist diese Technik sehr sinnvoll, da in Spiele 3D Engines sogut wie nur Volltexturierte Polygone verarbeiten. Bei professionellen Anwendungen, die größtenteils im Wireframemodus operieren, ist es wohl nicht sonderlich sinnvoll, da ja HSR hier nichts bringt. Aber für Gamer Grafikkarten ist dieses Konzept wohl eine gute Möglichkeit die Effizienz des Chips zu erhöhen, und Resourcen in Form von Speicherbandbreite zu sparen. Das Problem mit hohen Polycounts ist eigentlich kein Problem, wenn genug Speicherplatz vorhanden ist, um jeweils zeitgemäß komplexe Szenen dort zu speichern.

[StefanV]

Originally posted by Legolas
Und wer hat diesen ominösen Chip entwickelt? Würde mich brennend interessieren, weil ich davon noch nix gehört hab. Kannst du vielleicht auch etwas mehr über dieses alternative Konzept für SGI-Renderer sagen, oder weißt du auch nicht mehr?

Ja, hatte eine eigene API, und es gab ihn zu den Anfangstagen der 3D Ära...

Wenn ich mich nicht irre, dann gab es nur 2 Chips, der letzte war gegen die NV3 positioniert...

PS: ich hab gesagt, daß dieser Chip einen VS haben könnte, von der Geschwindigkeit hab ich NIX gesagt...

Jedenfalls wäre sie grottenschlecht (Chip mit 50(!!)MHz Getaktet, bei Hercules mit 62,5Mhz)...

Ich könnte auch den Namen der Hercules Karte Posten, oder die API, aber dann wäre das ja zu einfach;)...

Oh, 'kleiner' Tip:

Dieses Unternehmen wurde von einem 'Goßen' der Branche 'aufgefressen', und es war KEIN Hersteller, der was mit Grafik Chipsätzen zu tun hat...

[Legolas]

Meinst du vielleicht die Rendition Verité Reihe??

Soviel ich weiß gab es mal eine Karte ich glaub mit dem 2200er und nem Geometriechip... aber daß der vom Prinzip anderst gearbeitet hätte, wie andere Brute Force Renderer.. das wär mir neu..

Also, wenn es ein Rendition war, dann muss es entweder der V2100 oder V2200 sein, wobei der v2100 die LowCostversion vom 2200er war. Ach ja, die Schnittstelle von Rendition hieß RRedline :)... mehr gibt mein Gedächtnis dazu nicht her :D:D

[Ceiser Söze]

Vielleicht meint er auch den "PixelSquirt" (oder wie das Ding auch immer hiess - blöder Name, übrigens) von Stellar Semiconductor.
Das Ding hat meines Wissens auf sog. "Scanline-Rendering" gesetzt, was einen ähnlichen Effekt wie Tile-Based Rendering gehabt hätte und sollte auch ohne Z-Buffer auskommen. Er wäre ausserdem sehr klein gewesen (Unter 1 Mio. Transistoren).
Aus dem Chip wurde nichts und die Firma wurde von Broadcom aufgekauft...

Aber vermutlich meint er doch den Rendition-Chip: Er hatte eine eigene API, einen RISC-Core im Chip (programmierbar --> Vertex-Shader), einen speziellen Renderingansatz ("Asynchronous Rendering") und die Firma wurde am Ende von Micron gekauft...

[StefanV]

Ja, ich meinte die Chips von Rendition...

Es gab übrigens auch einen V1000...

Ich hab ja auch von einem SGI Renderer gesprochen;)...

Und der andere Ansatz ist eben der RISC Core, den diese Chips hatten, alle anderen arbeiten ja 'geordnet'...

Man könnte theoretisch diese Chips mit einem anderen Treiber neue Features spendieren...

Oder für andere Dinge 'misbrauchen'...

Ich halte den Ansatz von Rendition für sehr gut.

Ein Spiel könnte dem Chip ja auch andere Aufgaben als 3D Rendering übergeben ;)...

[Legolas]

Wobei der V1000 wohl kaum gegen den Riva 128 positioniert worden ist :D:D

[StefanV]

Originally posted by Legolas
Wobei der V1000 wohl kaum gegen den Riva 128 positioniert worden ist :D:D

Stimmt, dieser Chip gehört eigentlich zu den 3D Bremsen...

Also zu S3 Virge, MGA Mystique (wie war's Matrox hat keine Chance mehr auf den Gamer Markt??)...

Schade, daß neue 3D Beschleuniger keinen RISC Kern mehr haben...

[Matrix316]

Moment, die Mystique und die Millenium waren damals richtig schnell, nur sah es eben bescheiden aus...

[StefanV]

Originally posted by Matrix316
Moment, die Mystique und die Millenium waren damals richtig schnell, nur sah es eben bescheiden aus...

Richtig, offiziell hat Matrox gesagt, das sie es für sinnvoller halten die Karte Spiele zu beschleunigen...

[Legolas]

Originally posted by Stefan Payne


Richtig, offiziell hat Matrox gesagt, das sie es für sinnvoller halten die Karte Spiele zu beschleunigen...

??? Irgendwie kapier ich den satz nicht...

[StefanV]

Originally posted by Stefan Payne
Richtig, offiziell hat Matrox gesagt, das sie es für sinnvoller halten die Karte Spiele zu beschleunigen...

Ich sollte mir wohl mal abgewöhnen 'halbe' Postings zu schreiben;)...

Also:

Matrox hat auf Filter verzichtet, weil die Karte dann zu langsam wäre.

Sie haben es für sinnvoller gehalten auf die Filter zu verzichten, aus Performance Gründen...

[Legolas]

Naja, soviel ich weiß, konnte die Matrox Mysique nichtmal Alpha Blending, sondern hat nur ein einfacheres Verfahren benutzt :D:D

[StefanV]

Originally posted by Legolas
Naja, soviel ich weiß, konnte die Matrox Mysique nichtmal Alpha Blending, sondern hat nur ein einfacheres Verfahren benutzt :D:D

Genau;)...

[Quasar]

Moin!

Ich hab mir neulich noch mal nen V2200 für beinahe null kohle besorgen können (ich bin Nostalgiker :) ) und der kann mit ner V1 durchaus gut mithalten...leider habe ich nur die version mit 4MB erwischt und mit den Treibern sieht es auch nicht mehr so dolle aus....musste ganz schön rumprobieren, bis es vernünftig lief...

Das schöne an dem Core ist wirklich, daß es der oben benannte Risc-Core ist, der mit Microcode halbwegs frei programmiert werden kann...

Aber zurück zum TBR...im moment kann man von diesem Design sicher noch einiges erwarten und die Marktführer könnten sich von dessen effizienz sicher auch noch ne scheibe abschneiden, nur wie gesagt, wird das Design an sich, wenn es sich erst einmal durchgesetzt hat, auch wieder in richtung BFR gehen und damit quasi seinen Reiz verlieren...

Einen vorteil sehe ich jedoch auf lange sicht noch:
aufgrund der schon vorhandenen Tile-Architektur scheint sich dieses Design bestens für massiv parallele systeme zu eignen und da die Tiler an sich relativ simple designs sind, ist es sicher auch nicht allzu teuer, mehrere davon auf einer Karte zu verbauen...
Schön wäre es weiterhin, wenn man das design nutzen könnte, um eine evtl. auch vorhandene TnL Engine von überflüssigen Polygonen zu entlasten, indem man die über den bus empfangenen Polygone *vor* dem Setup und der Weiterverarbeitung einfach mal z-checked.....

[Legolas]

Ich glaube Quasar, da hast du einen kleinen Denkfehler gemacht: Vor der Transformation kann man doch noch kein HSR durchführen, weil die Entgültige Position der Dreiecke auf dem Bildschirm doch erst duch die Transformationsengine festgelegt wird...

Ach ja, und zum V2200: Der ist doch über ein Jahr nach dem Voodoo 1 auf den Markt gekommen, ein paar Monate vor dem Voodoo 2.

[ow]

Originally posted by Quasar


Einen vorteil sehe ich jedoch auf lange sicht noch:
aufgrund der schon vorhandenen Tile-Architektur scheint sich dieses Design bestens für massiv parallele systeme zu eignen und da die Tiler an sich relativ simple designs sind, ist es sicher auch nicht allzu teuer, mehrere davon auf einer Karte zu verbauen...





Na dann darfst du jetzt hier erklaeren, warum beispielweise das "simple design" eines Tilers auf einer Kyro2 mal eben 15Mio. Transistoren verbraet.

Ein Tiler ist wesentlich komplexer als ein traditioneller Renderer!

[Quasar]

@Legolas:
Was die V2200 angeht, hast du natürlich recht...sie war halt zur falschen Zeit am falschen Ort...Mal wieder ein typisches Beispiel dafür, was mit Firmen passieren kann, wenn sie ihre Produkte vertrödeln...
Was das Polygon-Clipping angeht, so war das nur eine vermutung von mir, ich bin mir da keineswegs sicher, wie und ob das überhaupt funktionieren könnte...ich glaube aber, daß eine gewisse "grundordnung" schon in den Geometridaten enthalten ist, die die TnL Engine von der CPU geliefert bekommt....

@ow
das will ich gerne mal versuchen:
Zunächst einmal hab ich vom Tiler an sich gesprochen, damit meinte ich *nur* die Tilereinheit, ohne 2d-Kern, ohne 3d-Pipeline, ohne Textureinheiten. Ferner sind auf den Tiler-Chips prinzipiell bedingt relativ große Bufferbereich enthalten, da immerhin nicht nur ein einzelner (oder von mir aus auch mehrere) Pixel sondern ein ganzes Array derselben bearbeitet werden muß...und cachè-bereiche (mit ausnahme der anbinduns-logik) gehören nun mal zu den simpelsten designs der ganzen prozessor-technologie...
Schön zu sehen ist das m.E. in der Erhöhung der Transistorzahl vom KyroI auf den IIer um 3millionen...bei ansonsten *gleichen* features...

[ow]

@quasar


Also du meinst, dass zusaetzliche Recheneinheiten auf einem Chip nichts kosten??
Nur weil das tiling theoretisch einfach zu parallelisieren ist??

[Quasar]

Ich meine nicht, daß sie nichts kosten, ich meine, daß sie *verhältnismäßig* wenig kosten, da man ein vorhandenes Design mehrfach verwenden kann...

[ow]

Originally posted by Quasar
Ich meine nicht, daß sie nichts kosten, ich meine, daß sie *verhältnismäßig* wenig kosten, da man ein vorhandenes Design mehrfach verwenden kann...

Das spielt nur eine untergeoordnete Rolle.

Mehr Transistoren -> groesseres DIE -> weniger DIEs pro SIlizium-Wafer -> TEUER

Andernfalls wuerde deine Aussage auf alle Einheiten eins Chips zutreffen ("..dann bauen wir doch noch 16 texturing units rein, design ist vorhanden, also kostet's verhaeltnismaessig wenig..").

[Thowe]

Originally posted by ow



Mehr Transistoren -> groesseres DIE -> weniger DIEs pro SIlizium-Wafer -> TEUER



plus andere Probleme die auftauchen können, also in der Summe eher nicht rentabel.

[ow]

Originally posted by Thowe


plus andere Probleme die auftauchen können, also in der Summe eher nicht rentabel.


Jaja...;) , ich wollte das bloss nicht noch weiter ausfuehren.


Wenn's so einfach waere, wie Quasar sich das denkt, dann haette der Kyro sicher mehr Tiling- u. Texturing-Units.

[Quasar]

Also eigentlich hab ich von mehreren Tilern auf einer Karte, nicht auf einem Chip, gesprochen. Mir ist schon klar, das es nicht umsonst ist, auch simple Chips herzustellen. Aber es scheint mit auf jeden Fall sinnreicher, ein vorhandenes Design erst einmal auszureizen, indem man z.B. eine Karte mit einfachem Tiler für den mainstream Markt anbietet und eine andere Karte, mit z.B. 2 Tilern (und entsprechendem Hinterbau!) für den High-End Markt.

Natürlich ist es auch so, daß es mehr kostet, eine Karte mit mehreren IC's herzustellen, als eine mit wenigen.
Aber gerade dadurch, daß die einzelnen Chips relativ klein und simpel gehalten werden können, erhöht man auch den Yield der gesamten Produktion. Und meines Wissens ist es auch so, daß, je weniger Transistoren ein Chip hat, er umso übersichtlicher zu designen ist, es umso einfacher ist, die treiber dafür zu schreiben und so weiter....

Das ist eben die crux mit komplexen systemen, daß sie mit fortschreitender Entwicklung auch zunehmend unübersichtlich und unbeherrschbarer werden. Man nehme z.B. mal den S3TC-Bug in der GF256ff. Ich glaube nicht, daß nVidia seine (ihre?) Chip-Designs nicht genau überprüft, bevor sie zum Tape-out und in die Massenproduktion gelangen....aber der Fehler scheint hier so tief im Design zu stecken, daß man ihn selbst zwei Generationen später nicht austreiben hat können.
Ein anderes Beispiel ist die von *ntel herausgegebene Liste mit "Errata" zu ihren CPU-Designs....nicht umsonst hat der P4 als bislang komplexeste Desktop-CPU auch die längste liste an bekannten Prozessorfehlern.

[StefanV]

Also so in etwa einen Chip, der recht 'doof' ist und nur rendern kann und einen, der den ganzen 'unterbau' beherrbergt ;)...

So könnte man die Karten ganz einfach beschleunigen ;)...

Einfahc einen Chip mehr drauf packen ;)...

Von der Verlustleistung und der Taktfrequenz reden wir nicht ;)...

[Quasar]

Im Prinzip: ja.
Was das allerdings mit der Taktfrequenz zu tun hat, leuchtet mir nicht so recht ein.

Das Problem, das (nicht nur ich) für die nähere zukunft sehe ist nur, daß sich die Fertigungstechnik nicht mehr beliebig verfeinern läßt...irgendwann kommen halt mal physikalische grenzen auf uns zu. Man sieht das ja allein schon daran, wieviele anläufe nVidia gebraucht hat, um seinen GF3 endlich zur Produktionsreife zu bringen, ein Mitgrund dafür war wohl, daß die *SOFTWARE*-Entwicklungstools einfach nicht für einen so komplexen chip ausgelegt waren, ein anderer, daß TSMC gerade erst den .15mikron-Prozess eingeführt hat.
Ihr glaubt doch wohl nicht, daß sich das mit der Zeit bessert, oder? Im gegenteil, es wird immer schlimmer werden, schätze ich...
Außerdem braucht man sich nur mal professionelle OpenGL-Karten oder auch komplette IT-systeme anzuschauen, um zu sehen, daß parallelisierung der weg der zukunft ist.

Was meint ihr im übrigen, hat *alle* grafikchiphersteller veranlasst, ihre chips mit mindestens zwei Renderingpipelines herzustellen? Parallelisierung!

Nur ist das in diesem Maße irgendwann nicht mehr sinnvoll innerhalb eines Die, so daß man sich gedanken machen muss, wie man den unstillbaren Durst der User befriedigen kann...

Was ist mit der von *ntel angeforschten sog. Jackson-Technologie oder den in Entwicklung befindlichen CPU's von IBM (name ist mir leider entfallen)?

P.S.: Außerdem gab es dal noch so eine Firma, vielleicht könnt ihr euch ja an den Namen erinnern, die habe ihre ersten Beiden Karten auch mit mehreren spezialisierten Chips ausgestattet. als sie dann versucht haben, alles in einen core zu integrieren, gingen ihre probleme los. der erste brauchte gar 7 steppings, bis er in massenproduktion ging, was alle darauffolgenden projekte so sehr verzögerte, daß man am ende mit einer Generation rückstand vom ärgsten Rivalen aufgekauft wurde...

[Thowe]

Originally posted by ow



Jaja...;) , ich wollte das bloss nicht noch weiter ausfuehren.


Wenn's so einfach waere, wie Quasar sich das denkt, dann haette der Kyro sicher mehr Tiling- u. Texturing-Units.

Dachte ich mir, dass du das weisst. =)

@All, man kann nicht einfach Technology in ein bestehendes Design reinbacken, dass ist schon etwas komplexer.

[ow]

@ Quasar


Du solltest dich erst mal festlegen wovon du redest!

Erst redest du von der reinen Tiling Unit OHNE 2D core, 3D core etc.... und dann von einer Karte mit mehreren Chips??

Was denn nun??


Und um physikalische Grenzen brauchst du dich jetzt nicht zu sorgen, da ist in den nächsten 10 Jahren kein Problem zu erwarten.

[StefanV]

Originally posted by Quasar
Im Prinzip: ja.
Was das allerdings mit der Taktfrequenz zu tun hat, leuchtet mir nicht so recht ein.

Ganz einfach:

Einfachere Chips, weniger Transistoren, Höhere Taktfrequens, geringere Verlustleistung eines einzelnen Chips...

[Quasar]

@Stefan Payne:
Sorry, ich dachte, du meintest das ironisch...du hast natürlich recht!

Originally posted by Quasar

Einen vorteil sehe ich jedoch auf lange sicht noch:
aufgrund der schon vorhandenen Tile-Architektur scheint sich dieses Design bestens für massiv parallele systeme zu eignen und da die Tiler an sich relativ simple designs sind, ist es sicher auch nicht allzu teuer, mehrere davon auf einer Karte zu verbauen...

Zunächst einmal sorry, daß ich mich selbst zitiere, aber es scheint ja nötig zu sein.

Mein lieber ow, ich glaube du bist es, der sich mal auf etwas festlegen sollte.
Zuerst verwechsest oder mißverstehtst du meinen Bezug auf die Tiler und möchtest die 15mio Transistoren auf einer KyroII erklärt haben, dann fängst du an, auf die Kosten auszuweichen, dann unterstellst du mir ich hätte von *einem Die* geredet und nun muß ich von *dir* hören, ich wechsle das thema?


Noch mal von Vorne:
Ich rede von einer *fiktiven* Grafikkarte, die mehrere simple Tiler-chips enthält und zwar zusätzlich zu einem ganz normalen Graka-Core mit 2d-pipe, 3d-pipe, einigen widerständen, spannungswandlern, etvl einem TV-out chip, ausreichenden speicher und allem was sonst noch dazu gehört.

Wenn man mich mißverstehen *will*, dann kann man das natürlich drehen und wenden wie man möchte...oder paßt es dir einfach nicht, daß ich als Newbie mit nur 10posts einfach so in euer allerheligstes Technologie-forum poste?
Wenn ja, dann sag es bitte direkt!

und was die physikalischen Grenzen angeht, so sind wird, zumindest, was teilbereiche der technologie angeht, schon dichter daran, als es vielleicht den anschein hat. Oder wie erklärst du dir, daß z.B. die *reine Rechenleistung* von Grafik*chips* schon seit längerem nicht mehr im Verhältnis zum Ausbau /zur Leistungsfähigkeit des Speichers samt seinem Interface steht? daß z.B. die alle nVidia-Karten mind. seit der GF2 an eklatantem Mangel an Speicherbandbreite leiden? Ganz einfach deswegen doch wohl, weil selbst heute eine reale Frequenz von ca. 260-280MHz DDR das Maximum darstellt, was im Massenmarkt zu kaufen ist...

[HOT]

Da kann ich dir nur zustimmen. Aber ich muss nochwas hinzufügen: wäre es nicht sogar theoretisch denkbar das Tile "an sich" zu parallelisieren? z.B. 2 oder 4 Tiles "auf einmal berechnen".
Noch was zu Transistorgrösse: Bei Chips, die 60Mio Transostoren besitzen sind 5 Mio mehr Transistoren wohl ein sehr guter Tausch für 30% Performance-Boost, oder? Zumal man in den weiteren 5 Mio (vielleicht auch mehr) auf grund ihreres einfachn designs eigentlich keine Bugs miteinbauen kann. Der Chip wird zwar geringfügig teurer, aber das schmälert das Preis/Leistungsverhältnis nicht.

[Quasar]

Mir fällt auf Anhieb eigentlich kein Grund ein, warum Tiles nicht paralellisierbar sein sollten. Im Gegenteil, aufgrund des Tile-Prinzips müsste eigentlich eine parallele Architektur einfacher als bei SGI-Renderern durchführbar sein.
Das einzige Problem ist IMHO folgendes: Wenn es stark unterschiedlich komplexe Tiles innerhalb eines Frames gibt, wird der gesamt Frame auf die Geschwindigkeit des langsamsten Tiles reduziert (mal angenommen, wir hätten den Idealfall, daß alle Tiles gleichzeitig berechnet würden)....ein Worst-Case Speed-up sozusagen...

[HOT]

Stimmt, das Problem besteht in der Tat. Aber könnte man das nicht umgehen, wenn man Tiles mit Variabler grösse einführt? Also quasi Tilen mit Objekterkennung? Das würde das Problem dieses Overheads in den Griff bekommen und die Geschwindikkeit wäre nicht mehr vom langsamsten Glied abhöngig sondern würde sich eher mitteln.

[Quasar]

Ich weiß nicht, so gut kenne ich mich da nicht aus, aber Tilen mit Objekterkennung halte ich für etwas schwierig, da durch einen einfachen Z-Abgleich noch nicht ein Objekt zu definieren ist...
Außerdem bleiben bei variabler Größe auch immer krumme/kleine Tiles übrig, wodurch dann das zusammensetzen zu einem kompletten Frame für den Framebuffer schwierig, aber nicht unmöglich, wird.
Was dann bei einem eventuell nötigen zweiten Pass passiert, will ich gar nicht wissen, da kleine Fehlerchen sich evtl. addieren könnten.

P.S.: Auch wenn eine Objekterkennung funzen sollte, löst das noch lange nicht das problem, daß auf verschiedenen Objekten auch verschiedene Texturoperationen zum Zuge kommen. Bsw. muß durchaus nicht eine ganze Szene mit EMBM bedacht werden, einige Objekte reichten durchaus.

[Legolas]

Also bei der Parallelisierung der Tileberechung sollte es keine Probleme geben... soviel ich weiß, werden in einigen Spielautomaten von Sega mehrere PowerVR SG eingesetzt... und von denen berechnet einer die geraden, der andere die ungeraden Tiles. Prinzipiell ist dies also sehr gut möglich.. ich glaube auch, daß der Kyro zumindest theoretisch multichipfähig ist (bin mir da aber nicht sicher). Irgendwo hab ich auch mal ne Aussage über die verschiedenlangen Berechnungzeiten der einzelnen Tiles gelesen.. und da stand, daß die nicht so stark voneinander differieren, dass es da zu Problemen kommen kann.. Naja, und da es bei 2 verschiedenen Chips geht, kann man das ganze natürlich auch auf einen einzigen Die basteln...

[HOT]

Parallele Chips sind natürlich eine Lösung. Dann könnten sie sich jeweils um ein Tile abwechseln. Viele Texturüberschneidungen wird es dann auch nicht mehr geben.
Zu den variablen Tiles: Die Tilegrösse müsste evtl. während des Raycastings bestimmt werden, um die Komplexität. des Tiles zu ermitteln. Das wäre zwar dann nicht Objektbasiert, aber effizienter.
Aber ich habe noch einen Vorteil entdeckt:
Ausserdem könnte man in einen Tiler ein echtes HardwarFSAA integrieren. Man müsste die Tiles einfach in 4-facher oder 8-facher Auflösung einlesen. Da jeder Pixel gecheckt wird, müsste man dann nur 4x soviel Checken, am besten in 4er Blöcken. Dann wäre es allerding auch nötig das Tile durch 4 zu teilen. Da kommt die Parallelisierbarkeit der Tiles ins Spiel. Die Komplexität der Scene ändert sich ja nicht, sodass eine erhöhung der machimalen Z-Layer des Raycastings nicht nötig wäre (wobei auch das kein Problem darstellt). Währenddessen, wäre es sogar möglich, jeweils ein 4er Block von Pixeln zu "verdrehen", um genauere Mittelwerte zu ermitteln. Zuletzt müsste die Scene dann heruntergerechnet werden.
Ich glaub, dass Dingen müsste man dann extra deferred Renderer nennen :D

[Xmas]

Was zum Henker ist denn "echtes HardwareFSAA"???

Einer der großen Vorteile, die ich bei TBR sehe, ist die einfache Implementierung fortgeschrittener FSAA-Methoden. Denn die Dreiecke werden ja nicht in Scanlines, sondern in Pixel zerlegt, die per Raycasting auf Sichtbarkeit getestet werden. Hier ist es also möglich, für jeden Pixel die Sampleposition individuell zu steuern, während das beim normalen Triangle Setup mit Scanline-Zerlegung problematisch ist, weil die vertikale Sampleposition für die gesamte Scanline gleich bleiben muss.
Zudem kann das Herunterfiltern recht einfach in den Schreibvorgang zum Framebuffer integriert werden, weshalb für FSAA weder mehr Bandbreite (zum Framebuffer, Texturbandbreite schon) noch mehr Speicherplatz benötigt wird. Nur die Tiles werden effektiv kleiner, also muss der OnChip-Buffer groß genug sein.