Tiling & Tessellation

[del_4901]

DX11 Featureset mit nem TBR wird nicht einfach. Tessellation ist ein grosses Problem fuer einen TBR. Obwohl GCN nun auch nicht wirklich ein Tesselationsmonster ist.

[Coda]

Wie hat das PowerVR eigentlich gelöst? Ich hab dazu irgendwann mal ein Patent gesehen :)

[del_4901]

Wie hat das PowerVR eigentlich gelöst? Ich hab dazu irgendwann mal ein Patent gesehen :)Geloest haben Sie noch gar nichts: Die haben einfach noch keine Hardware mit Tessellation, weil es einfach ineffizient wird. Das waehre ja fast so, als wuerde GCN Tessellation ueber Memory machen, nur das GCN mehr Bandbreite hat. ;)

[Coda]

Ich dachte Series 6 könnte DX11? Wo ist eigentlich überhaupt das große Problem? Sie müssen ja auch die Vertex-Shader vor dem Binning laufen lassen. Und Geometry-Shader haben ja auch Geometry-Expansion.

[del_4901]

Ich dachte Series 6 könnte DX11? Wo ist eigentlich überhaupt das große Problem? Sie müssen ja auch die Vertex-Shader vor dem Binning laufen lassen. Und Geometry-Shader haben ja auch Geometry-Expansion.Man kann das Binning erst nach dem GS machen. Die Amplification vom GS ist nicht so gross wie die von Tessellation. Ausserdem verwendet kaum Jemand GS weil die Geschwindigkeit sich in Grenzen haelt, es faellt also kaum auf wenn es langsam wird. ;)

[Coda]

Und was ist das Problem, dass man das Binning erst nach dem GS machen kann?

Die Geometrie kann doch vom Arbitter einmal quer über alle Cores verteilt werden dafür und danach in durch nen FIFO ins Binning. Oder ist das der Flaschenhals?

Oder die Speicherbandbreite weil man das ganze erstmal rausschreiben muss und nicht auf dem Chip weiterverarbeitet?

[del_4901]

Und was ist das Problem, dass man das Binning erst nach dem GS machen kann?

Die Geometrie kann doch vom Arbitter einmal quer über alle Cores verteilt werden dafür und danach in durch nen FIFO ins Binning. Oder ist das der Flaschenhals?Ein TBR geht ueber Memory alle Dreiecke werden erstmal in den Parameterbuffer geschrieben. Erst wenn das erledigt ist rastert man. Wenn der Parameterbuffer 'voll' laeuft kann dann muss man schon eher anfangen Tiles zu rastern. In dem Fall muss man aber Tiles (inclusive Z) rausschreiben und spaeter wieder einlesen und fertig rastern. Wenn das oefter passiert dann ist es nicht mehr effizient.

Oder die Speicherbandbreite weil man das ganze erstmal rausschreiben muss und nicht auf dem Chip weiterverarbeitet?Genau! Der Parameterbuffer liegt auch Off-Chip, viele kleine Dreiecke blaehen den auch auf.

[Coda]

Kapiert, danke. Ich hab mich eh schon öfters gefragt wie die mit theoretisch unbeschränkten Datenmengen von der API aus umgehen.

[del_4901]

Kapiert, danke. Ich hab mich eh schon öfters gefragt wie die mit theoretisch unbeschränkten Datenmengen von der API aus umgehen.Das ist auch der Grund warum klassische Gbuffer nicht so populaer sind auf einem TBR.

[mboeller]

Wie hat das PowerVR eigentlich gelöst? Ich hab dazu irgendwann mal ein Patent gesehen :)


das hier?
http://www.highbeam.com/doc/1P3-2504268751.html

und nein, ich habe es nicht gelesen, nur 1min google.suche.

[Ailuros]

Wenn ich mich nicht verrechnet habe, schafft die GPU im 5S 110,85 GFLOPs bei FP32, der A4-5000 (Kabini) kommt auf 128 GFLOPs und der A6-1450 (Temash) auf 102,4 GFLOPs (wenn die 400MHz mal gehalten werden). Dass reine FLOPs nicht alles sind, ist allerdings klar.

Natuerlich; der Rogue hat garantiert eine hoehere Fuellraten-Effizienz u.a.

DX11 Featureset mit nem TBR wird nicht einfach. Tessellation ist ein grosses Problem fuer einen TBR. Obwohl GCN nun auch nicht wirklich ein Tesselationsmonster ist.

Hast Du schon mit einem Rogue tesselliert?

Ein TBR geht ueber Memory alle Dreiecke werden erstmal in den Parameterbuffer geschrieben. Erst wenn das erledigt ist rastert man.

Nein zum letzten.

Wenn der Parameterbuffer 'voll' laeuft kann dann muss man schon eher anfangen Tiles zu rastern.

Wobei man es auch so verdammt uebertreiben muss damit DIE buffer (ja es ist nicht nur einer) voll werden, wobei ein IMR in solchen Faellen genauso schnell krepiert.

In dem Fall muss man aber Tiles (inclusive Z) rausschreiben und spaeter wieder einlesen und fertig rastern. Wenn das oefter passiert dann ist es nicht mehr effizient.

Genau! Der Parameterbuffer liegt auch Off-Chip, viele kleine Dreiecke blaehen den auch auf.

Das Zeug ist zwar verdammt OT, aber das obrige Maerchen lese ich schon seit Jahren und es wird leider blindlings verbreitet ohne dass es wirklich der Realitaet entspricht. Es ist wahr dass Tilers generell einen Haufen Zeit verbringen Geometrie herumzupuffern, aber dabei macht es dann keinen besonderen Unterschied mehr ob IMR oder DR. Ganz im Gegenteil hat der deferred renderer hier eher Vor- als Nachteile.

In Sachen Geometrie haben SGX cores jeder ULP Konkurrenz mit grossen Unterschieden den Hintern eingereicht wenn es zu Geometrie kommt in Echtzeit und in benchmarks. Warten wir ergo lieber ab bis wir einen DR tessellieren sehen bevor wir zu Schlussfolgerungen kommen nach einfachem hoerensagen.

Und was ist das Problem, dass man das Binning erst nach dem GS machen kann?

Die Geometrie kann doch vom Arbitter einmal quer über alle Cores verteilt werden dafür und danach in durch nen FIFO ins Binning. Oder ist das der Flaschenhals?

Oder die Speicherbandbreite weil man das ganze erstmal rausschreiben muss und nicht auf dem Chip weiterverarbeitet?

http://worldwide.espacenet.com/publicationDetails/biblio?DB=EPODOC&II=17&ND=3&adjacent=true&locale=en_EP&FT=D&date=20130626&CC=CN&NR=103180882A&KC=A

DX11.x Rogue Varianten sind lediglich noch nicht angekuendigt; diese werden mit einer zusaetzlichen Tesselations-Einheit kommen.

[del_4901]

Hast Du schon mit einem Rogue tesselliert?Ne, es geht ja nicht. ;-)

Nein zum letzten.http://www.unrealengine.com/files/downloads/Smedberg_Niklas_Bringing_AAA_Graphics.pdf

Wobei man es auch so verdammt uebertreiben muss damit DIE buffer (ja es ist nicht nur einer) voll werden, wobei ein IMR in solchen Faellen genauso schnell krepiert.Nvidia skaliert sehr gut mit Geometrie.

Das Zeug ist zwar verdammt OT, aber das obrige Maerchen lese ich schon seit Jahren und es wird leider blindlings verbreitet ohne dass es wirklich der Realitaet entspricht. Es ist wahr dass Tilers generell einen Haufen Zeit verbringen Geometrie herumzupuffern, aber dabei macht es dann keinen besonderen Unterschied mehr ob IMR oder DR. Ganz im Gegenteil hat der deferred renderer hier eher Vor- als Nachteile.Von Anderen behaupten sie würden Märchen erzählen ohne selber aufzuklären ist keine feine Art. Du willst doch sicher nicht, das ich deine Aussagen als Fanboygelaber abstempel.

In Sachen Geometrie haben SGX cores jeder ULP Konkurrenz mit grossen Unterschieden den Hintern eingereicht wenn es zu Geometrie kommt in Echtzeit und in benchmarks. Warten wir ergo lieber ab bis wir einen DR tessellieren sehen bevor wir zu Schlussfolgerungen kommen nach einfachem hoerensagen.
Verwechsle hier Geo nicht mit Fuellrate. Das Binning kann erst nach dem VS, GS gemacht werden, bis hier sind IMR und DFR gleich, nur das ein IMR viel mehr Rohpower hat.

http://worldwide.espacenet.com/publicationDetails/biblio?DB=EPODOC&II=17&ND=3&adjacent=true&locale=en_EP&FT=D&date=20130626&CC=CN&NR=103180882A&KC=A

DX11.x Rogue Varianten sind lediglich noch nicht angekuendigt; diese werden mit einer zusaetzlichen Tesselations-Einheit kommen.Abwarten und Tee trinken.

[Ailuros]

Ne, es geht ja nicht. ;-)

Ergo ueberlassen wir die Schlussfolgerungen fuer Tessellation fuer die Zukunft?

http://www.unrealengine.com/files/downloads/Smedberg_Niklas_Bringing_AAA_Graphics.pdf

Es wird zuerst verworfen und dann gerastert zumindest afaik.

Nvidia skaliert sehr gut mit Geometrie.

ULP GFs in Tegras sind keine besondere Geometrie-Wunder.

Von Anderen behaupten sie würden Märchen erzählen ohne selber aufzuklären ist keine feine Art. Du willst doch sicher nicht, das ich deine Aussagen als Fanboygelaber abstempel.

Ich hab den Fanboy-Stempel schon seit langem, ergo kostet es mich mehr Muehe das Gegenteil zu beweissen als sachlich beim Thema zu bleiben. Es gibt einen LINK zu einem Tessellations-Patent ganz unten in meinem vorigen Post von John Howson der der leading engineer fuer Serie5 und 6 ist. Hier noch mehr Lesematerial zum Thema vom gleichen Herren:

http://forum.beyond3d.com/showthread.php?p=1531013&highlight=tessellation#post1531013

Die allerersten SGX Einheiten hatten einen Tessellator (weiss der Geier um was es sich genau handelte) aber die Effizienz von dem Ding war unterirdisch. In Serie5XT wurde das Ding entfernt und man begrenzte es anstatt auf ~DX10 geometry shading. Es gibt mehrere Posts in dem obrigen thread aber ich bin zu faul jetzt alle herauszusuchen.

SGX ist am Rand effizienter mit sehr kleinen Dreiecken als so manche desktop GPU heute:

http://www.imgtec.com/demo_room/viewdemo.asp?DemoID=71&DemoTech=PowerVR%20Graphics&DemoDev=Imagination&#ViewPort


Verwechsle hier Geo nicht mit Fuellrate. Das Binning kann erst nach dem VS, GS gemacht werden, bis hier sind IMR und DFR gleich, nur das ein IMR viel mehr Rohpower hat.

Abwarten und Tee trinken.

Natuerlich abwarten und Tee trinken was anderes hatte ich gar nicht von Anfang im Hinterkopf. Sobald ein IMR tiling betreibt ist er genauso im Arsch mit der ganzen Pufferei wie jeglicher PowerVR. Das daemlichste ist dass ich zwar fuer rasterizing nichts anderes als tiling bevorzugen wuerde (unabhaengig von Architektur); die Geometrie-relativen Probleme lassen sich aber so wie ich es verstehe eben NICHT durch die heutigen APIs loesen wenn ueberhaupt.

Im Patent wird Tessellation durch 3 Phasen gezogen; auf Papier mag es Sinn machen aber ohne finale hw und die wahre finale Implementierung ditto generell.

[del_4901]

Es wird zuerst verworfen und dann gerastert zumindest afaik. Ich hab nie was anderes behauptet, nur wenn der Parameterbuffer voll laeuft muss er vorher schon abgearbeitet werden indem Tiles 'gespilled' werden um wieder Platz zu amchen. Das kostet dann sehr viel Bandbreite.

ULP GFs in Tegras sind keine besondere Geometrie-Wunder. Logan anyone?

Ich hab den Fanboy-Stempel schon seit langem, ergo kostet es mich mehr Muehe das Gegenteil zu beweissen als sachlich beim Thema zu bleiben. Und das macht dich jetzt glaubwuerdiger? Versuch es einfach mal nicht persoehnlich zu nehmen, ich hab einfach sachlich versucht Coda zu erklaeren wie ein TBR rendert, ohne Wertung. Bei IMR gibt es was Geometrie Leistung angeht auch so manches schwarzes Schaf.

Die allerersten SGX Einheiten hatten einen Tessellator (weiss der Geier um was es sich genau handelte) aber die Effizienz von dem Ding war unterirdisch.Jetzt weist du warum.

SGX ist am Rand effizienter mit sehr kleinen Dreiecken als so manche desktop GPU heute:

http://www.imgtec.com/demo_room/viewdemo.asp?DemoID=71&DemoTech=PowerVR%20Graphics&DemoDev=Imagination&#ViewPort Und die Schlussfolgerung machst du anhand eines Videos? Erst wenn Dreiecke kleiner als Quadgroesse werden, wird es wirklich unangenehm fuer einen IMR. (spezielle GS und Tess implementierungen mal aussen vor)

Sobald ein IMR tiling betreibt ist er genauso im Arsch mit der ganzen Pufferei wie jeglicher PowerVR. Das daemlichste ist dass ich zwar fuer rasterizing nichts anderes als tiling bevorzugen wuerde (unabhaengig von Architektur); die Geometrie-relativen Probleme lassen sich aber so wie ich es verstehe eben NICHT durch die heutigen APIs loesen wenn ueberhaupt. Ein IMR betreibt kein Tiling. Eine neue API hilft dir da auch nicht, weil man die ganze Szene kennen muss, bevor man binnen und sortieren kann. Da kann hoechstens was auf Engine Level machen.

[Ailuros]

Ich hab nie was anderes behauptet, nur wenn der Parameterbuffer voll laeuft muss er vorher schon abgearbeitet werden indem Tiles 'gespilled' werden, das kostet sehr viel Bandbreite.

Wie oft laeuft er denn voll realistisch?

Logan anyone?

Klingt sehr spezifisch. Wie viele trisetup/raster Einheiten und mit welchem Echtzeit throughput genau? Ein Schlagwort kann jeder in die Luft schmeissen ohne Einzelheiten.

Und das macht dich jetzt glaubwuerdiger? Versuch es einfach mal nicht persoehnlich zu nehmen, ich hab einfach sachlich versucht Coda zu erklaeren wie ein TBR rendert, ohne Wertung. Bei IMR gibt es was Geometrie Leistung angeht auch so manches schwarzes Schaf.

Wenn ich es nicht persoenlich nehmen soll dann verhalte Du Dich erstmal ein klein bisschen objektiver. Ohne jegliche hw Erfahrung mit Rogue zu haben ist es voreingenommen zu einer Schlussfolgerung zu kommen, genauso wenn Du nur "Logan" als Schlagwort in die Luft schmeisst. Wenn ich fuer Einzelheiten frage zum letzteren bekomm ich wohl das gleiche Schulterzucken wie fuer alles andere auch privat.

Jetzt weist du warum.

Das warum liegt woanders und es hat auch nichts mit der Debatte hier zu tun.

Und die Schlussfolgerung machst du anhand eines Videos? Erst wenn Dreiecke kleiner als Quadgroesse werden, wird es wirklich unangenehm fuer einen IMR. (spezielle GS und Tess implementierungen mal aussen vor).

Nein die Schlussfolgerung kommt nicht vom video.

Ein IMR betreibt kein Tiling. Eine neue API hilft dir da auch nicht, weil man die ganze Szene kennen muss, bevor man binnen und sortieren kann. Da kann hoechstens was auf Engine Level machen.

Dann sind Qualcomm's Adreno und ARM's Mali GPUs wohl nur ein Produkt meiner bunten Vorstellung oder was? Die beiden sind sehr wohl early Z tilers und eben nicht deferred renderers.

Und ja mir ist offensichtlich bewusst dass kein API helfen wuerde.

[Coda]

Dann sind Qualcomm's Adreno und ARM's Mali GPUs wohl nur ein Produkt meiner bunten Vorstellung oder was?
Nein, aber sie sind auch keine IMRs. Die machen genauso wie PVR Tile-Binning. Das einzige was sie nicht tun ist HSR, außer wohl Early-Z-Rejection.

[del_4901]

Nein, aber sie sind auch keine IMRs. Die machen genauso wie PVR Tile-Binning. Das einzige was sie nicht tun ist HSR, außer wohl Early-Z-Rejection.Exactly! Es kann sein dass sie fuer jedes Tile nen Z-prepass machen, aber das kann ich nicht mit Sicherheit sagen.

Wie oft laeuft er denn voll realistisch? Mit unseren Artists und Tessellation warscheinlich mehrmals pro Frame. Ideal sollte er niemals vollaufen, das kann man aber nur bei einer fixed Platform wie der VITA erreichen.

[Ailuros]

Nein, aber sie sind auch keine IMRs.

Es wird nicht "alles" systematisch verzoegert wie auf einem DR. Alles in Anfuehrungsstrichen weil es auch verdammt verschwommen in manche Faellen.

Die machen genauso wie PVR Tile-Binning.

Ja nur da es hier um Geometrie geht gehen beide Seiten (TBR/TBDR) total anders mit Geometrie vor. TBRs benutzen alle bounding box tiling; nur der PVR rastert auf tile level. Die relevanten Patente sind so "nutzlos" dass ARM mehr als einmal versucht hat sie anzufechten; vergebens.

Das einzige was sie nicht tun ist HSR, außer wohl Early-Z-Rejection.

Komisch formuliert da early Z schon im ersten pass visibility queries haben sollte.

Lange Geschichte kurz: IMHO wenn ein richtig entwickelter TBDR mit tessellation beschissen sein wird dann wird er es wohl auch mit ray tracing sein.


Mit unseren Artists und Tessellation warscheinlich mehrmals pro Frame. Ideal sollte er niemals vollaufen, das kann man aber nur bei einer fixed Platform wie der VITA erreichen.

Interessant. Hw relevante Fragen werde ich nicht stellen weil Du sie wohl nicht beantworten kannst; Tessellation aber auf sw level was genau? Das VITA hat im besten Fall irgendwelchen geometry shader Quark wenn ueberhaupt.

[Coda]

Es wird nicht "alles" systematisch verzoegert wie auf einem DR. Alles in Anfuehrungsstrichen weil es auch verdammt verschwommen in manche Faellen.
Verzögern oder nicht hat überhaupt nichts damit zu tun ob man tile based rendert oder nicht.

TBRs benutzen alle bounding box tiling; nur der PVR rastert auf tile level.
Das ist schlichtweg falsch. Ansonsten wäre Tiling völlig nutzlos. Die Chips binnen alles in Buckets, dann rendern sie jedes Tile komplett in den On-Chip-SRAM. Ob du da vollständiges HSR machst oder nicht hat nicht die Bohne mit IMR zu tun.

[Ailuros]

Es liegt gar nichts falsch daran, wir reden hier lediglich einander vorbei und wir haben hier den thread mit dem OT leider zu stark vergewaltigt ohne dass irgend jemand wenigstens um ein bisschen schlauer geworden ist.

[Coda]

Doch, es ist falsch. Bei allem Respekt, aber ich garantiere dir, dass du hier eine falsche technische Vorstellung hast.

Mali und Adreno und wie sie alle heißen werden nicht deshalb zu IMRs weil sie das Binning etwas anders machen. Das ist total absurd.

[Ailuros]

Doch, es ist falsch. Bei allem Respekt, aber ich garantiere dir, dass du hier eine falsche technische Vorstellung hast.

Wie dick ist denn die Wand mit der Du gerade Deinen Kopf durchboxen willst? Ich trau ein paar erfahrenen engineers auch die von ARM etwas mehr als Dir und nimm es mir nicht uebel, aber so bloed bin ich nun auch wieder nicht.

Mali und Adreno und wie sie alle heißen werden nicht deshalb zu IMRs weil sie das Binning etwas anders machen. Das ist total absurd.

The Mali GPUs use tile-based immediate-mode rendering.

For this type of rendering, the framebuffer is divided into tiles of size 16 by 16 pixels. The Polygon List Builder (PLB) organizes input data from the application into polygon lists. There is a polygon list for each tile. When a primitive covers part of a tile, an entry, called a polygon list command, is added to the polygon list for the tile.

The pixel processor takes the polygon list for one tile and computes values for all pixels in that tile before starting work on the next tile. Because this tile-based approach uses a fast, on-chip tile buffer, the GPU only writes the tile buffer contents to the framebuffer in main memory at the end of each tile. Non-tiled-based, immediate-mode renderers generally require many more framebuffer accesses. The tile-based method therefore consumes less memory bandwidth, and supports operations such as depth testing, blending and anti-aliasing efficiently.

Du kannst natuerlich auch den MALI engineers gerne erklaeren was sie genau ihre hw nennen wollen.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0363d/CJAEEJCF.html

[del_4901]

Wie dick ist denn die Wand mit der Du gerade Deinen Kopf durchboxen willst? Ich trau ein paar erfahrenen engineers auch die von ARM etwas mehr als Dir und nimm es mir nicht uebel, aber so bloed bin ich nun auch wieder nicht.
Dafuer aber Beratungsresistent und du fragst nicht nach wenn du dir schon was dazu dichtest: Coda und ich sprachen nur von einem TBR. TBDR/TBIR hast du dir dazu gedichtet. Ein TBIR muss genau wie ein TBDR erst die komplette Geo durchwuergen, bevor er anfangen kann mit rastern, wenn er keine Tiles spillen moechte.

[Ailuros]

Dafuer aber Beratungsresistent und du fragst nicht nach wenn du dir schon was dazu dichtest: Coda und ich sprachen nur von einem TBR. TBDR/TBIR hast du dir dazu gedichtet. Ein TBIR muss genau wie ein TBDR erst die komplette Geo durchwuergen, bevor er anfangen kann mit rastern, wenn er keine Tiles spillen moechte.

Ihr koennt Euch wohl trotz allem einig werden ob es am Ende tile based IMRs gibt oder nicht. Dafuer brauch ich keine Beratung.

Nebenbei warte ich immer noch auf eine Erklaerung was genau fuer "Tessellation" auf der Vita GPU benutzt wurde.

[Coda]

Die Dinger rendern nicht sofort, sondern verzögert nach dem Binning, damit sind es keine IMRs mehr.

Wenn die ihre eigene Architektur so wiedersprüchlich bezeichnen, ist das auch nicht mein Problem.

[Ailuros]

Es gibt keine Tile Based IMRs. Das ergibt Null Sinn.

Gut dann sind ARM und andere IHV die die Dinger so nennen einfach daemlich. Koennen wir zu etwas konstruktiverem kommen als nur Haare zu spalten? Von mir aus nenn sie borgo spinxter tilers.

Wenn die ihre eigene Architektur so wiedersprüchlich bezeichnen, ist das auch nicht mein Problem.

Soll ich es Dir vorzeichnen wie der obrige Satz genau bei einem dritten Beobachter ankommen koennte? Keep moving those goalposts.

Die Dinger rendern nicht sofort, sondern verzögert nach dem Binning, damit sind es keine IMRs mehr.

Lies mal genau den Link oben durch denn ARM erwaehnt mit Absicht nur fragment early Z; es gibt fundamentale Unterschiede sonst goennt ein europaeisches Patentamt nicht so leicht mehrere Patente; in den Staaten kann man vielleicht Dummheit patentieren :P

[del_4901]

Die Dinger rendern nicht sofort, sondern verzögert nach dem Binning, damit sind es keine IMRs mehr.
Naja man macht halt kein sorting und arbeitet nur auf dem OnChip-TileMemory um Bandbreite nach aussen und damit auch Strom zu spaaren. (Das Memory Interface verbraucht anteilig sehr viel)
Man kann den ParameterBuffer auch OnChip halten (oder ganz ohne arbeiten) und einfach oefter spillen.

[Ailuros]

Naja man macht halt kein sorting und arbeitet nur auf dem OnChip-TileMemory um Bandbreite nach aussen und damit auch Strom zu spaaren. (Das Memory Interface verbraucht anteilig sehr viel)
Man kann den ParameterBuffer auch OnChip halten und einfach oefter spillen.

Oder auch so:

http://worldwide.espacenet.com/publicationDetails/originalDocument?FT=D&date=20090923&DB=EPODOC&locale=en_EP&CC=GB&NR=2458488A&KC=A&ND=4

Ich muss Zeit finden und das ganze OT in einem anderen Thread schmeissen.

[del_4901]

Oder auch so:

http://worldwide.espacenet.com/publicationDetails/originalDocument?FT=D&date=20090923&DB=EPODOC&locale=en_EP&CC=GB&NR=2458488A&KC=A&ND=4

Ich muss Zeit finden und das ganze OT in einem anderen Thread schmeissen.
Dann einfach mal lesen:
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=46838&stc=1&d=1380721983

Die Erweiterung um den Statischen Teil ist ziehmlich sinnlos, Die Kamera will ja bewegt werden. Mag evtl. fuer fixed Kamera games interessant sein.

[Ailuros]

Dann einfach mal lesen:
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=46838&stc=1&d=1380721983

Die Erweiterung um den Statischen Teil ist ziehmlich sinnlos, Die Kamera will ja bewegt werden. Mag evtl. fuer fixed Kamera games interessant sein.

Hab ich das unterstrichene irgendwo bezweifelt? Im allerersten drawing sieht man aber auch superschoen dass HSR im rasterization stage vorgenommen wird genau nach dem parameter fetch. Sonst ist es je nach Anwendungsfall nicht nutzlos, hat aber nichts mit der Debatte direkt zu tun.

IMRs haben uebrigens afaik auch keine parameter buffer.

[S940]

Das wär doch im Technologie-Forum besser aufgehoben, oder? Spekuliert wird hier ja nichts, nur schön technisch hin- und hergeflucht *G*

[Ailuros]

Das wär doch im Technologie-Forum besser aufgehoben, oder? Spekuliert wird hier ja nichts, nur schön technisch hin- und hergeflucht *G*

Ich kann's auch ins techno-forum verfrachten aber dann geht den beiden Herren vielleicht die Lust aus weil das Rampenlicht dort geringer ist ;D

[Gaestle]

Hauptsache die Diskussion geht weiter. Interessant ist's allemal.

[Ailuros]

Hauptsache die Diskussion geht weiter. Interessant ist's allemal.

Lass Dich mal als Laie von 2 Entwicklern durch einen gangbang ziehen lassen und es ist sicher "interessant" :eek::biggrin: Ich muss nach Hause und etwas in meinen Notizen herumstoebern.

Den naechsten Schmarren den ich dann noch lesen werde ist dass wenn Xenos in der XBox360 zum "macro-tiling" kommt um alles in den eDRAM quetschen zu koennen dass es nicht Geometrie wiederpuffern muss nur weil es eben angeblich keine IMR tilers geben soll.:rolleyes:

[Coda]

Ailuros, eigentlich habe ich schon alles gesagt gehabt. Der einzige wesentliche Unterschied zwischen den TBRs und TBDRs ist, dass ImgTec noch komplettes HSR macht bevor sie zum Shading übergehen.

Ich geh davon aus, dass sie beim Shading auch keine Dreiecke mehr rastern sondern einfach über die Pixel laufen und dort schon die Informationen vorhalten die sie für den Pixel-Shader brauchen.

Und ich bezweifle auch nicht, dass das Binning und alles sehr viel ausgeklügelter ist bei ImgTec, vom Grundprinzip ist es aber das selbe.

[Gipsel]

The Mali GPUs use tile-based immediate-mode rendering.

For this type of rendering, the framebuffer is divided into tiles of size 16 by 16 pixels. The Polygon List Builder (PLB) organizes input data from the application into polygon lists. There is a polygon list for each tile. When a primitive covers part of a tile, an entry, called a polygon list command, is added to the polygon list for the tile.

The pixel processor takes the polygon list for one tile and computes values for all pixels in that tile before starting work on the next tile. Because this tile-based approach uses a fast, on-chip tile buffer, the GPU only writes the tile buffer contents to the framebuffer in main memory at the end of each tile. Non-tiled-based, immediate-mode renderers generally require many more framebuffer accesses. The tile-based method therefore consumes less memory bandwidth, and supports operations such as depth testing, blending and anti-aliasing efficiently.Du kannst natuerlich auch den MALI engineers gerne erklaeren was sie genau ihre hw nennen wollen.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0363d/CJAEEJCF.html
Je nachdem, wie stark man da noch weiter abspeckt, kann man am Ende auch unsere normalen Desktop-GPUs als tile based Renderer bezeichen.
(i) Framebuffer divided into tiles: check
(ii) geometry is binned to framebuffer tiles: check
(iii) ROPs work on onchip memory tile caches for increased bandwidth efficiency for blending and AA: check (zumindest bei AMD sind die sogar extra, bei nV ist das der L2)

Just my 2 cents.

Desktop-GPU machen das, um die Bandbreiteneffizienz zu erhöhen (das tut man selbst wenn die tile caches ständig in den VRAM geschrieben und neu gelesen werden müssen, die also ständig getrashed werden), aber auch als Mittel, um das Rastern und das Pixelbackend besser zu parallelisieren. Dreiecke, die in unterschiedlichen Screentiles liegen, können parallel gerastert werden (und man muß die Draw-Reihenfolge nicht mehr einhalten, weil sie nicht überlappen). Die Geometrie wird anhand der Screentiles in die sie fallen, auf die Rasterizer aufgeteilt (sowohl bei nV als auch bei AMD). Man "binned" also zwar im Prinzip in tiles (zumindest wird festgestellt, in welchem Tile das Dreieck liegt), sammelt aber die Geometrie vor dem Rastern nicht sondern macht direkt weiter.

[Ailuros]

Ailuros, eigentlich habe ich schon alles gesagt gehabt. Der einzige wesentliche Unterschied zwischen den TBRs und TBDRs ist, dass ImgTec noch komplettes HSR macht bevor sie zum Shading übergehen.

Ich geh davon aus, dass sie beim Shading auch keine Dreiecke mehr rastern sondern einfach über die Pixel laufen und dort schon die Informationen vorhalten die sie für den Pixel-Shader brauchen.

Und ich bezweifle auch nicht, dass das Binning und alles sehr viel ausgeklügelter ist bei ImgTec, vom Grundprinzip ist es aber das selbe.

Im Prinzip sind wir aber auf technischem Nivaeu kein Stueck weitergekommen. Vielleicht darf sich AlphaTier nicht ueber ihre Projekte weiter aeussern, aber ich behalte nach wie vor legitime Fragezeichen wenn er von "Tessellation" spricht auf einer GPU die offiziell nur DX9 unterstuetzt und etwas geometry shading zusaetzlich wohl kann. Weiss der Geier was sie genau anstellen.

Ich leih mir mal einen Ausschnitt aus einem uraltem Artikel von Wavey aus:

http://www.beyond3d.com/content/articles/4/5

Tiling mechanisms can operate in a number of ways. With immediate mode rendering (i.e. the pixels being rendered are for the same frame as the geometry being sent) it is never known what pixels the geometry is going to be mapped to when the commands begin processing. This is not known until all the vertex processing is complete, setup has occurred and each primitive is scan converted. So if you wanted to tile the screen with an immediate mode rendering system, the geometry may need to be processed, setup and then discarded if it is found not to relate to pixels that are to be rendered in the current buffer space. The net result here is that geometry needs to be recalculated multiple times for each of the buffers. Another method for tiling would be to use Tile Based Deferred Rendering which processes the geometry and "bins" it into graphics RAM, saving which render "tile" the geometry affects as it does so - these mechanisms have traditionally operated by deferring the actual rendering by a frame in order to parallelise the geometry processing / binning and the rendering (you may wish to take a refresher on PowerVR's tile based deferred rendering process in our article here).

Der Link ist fuer die Antiquitaet hier von 2001: http://www.beyond3d.com/content/articles/38/

...wobei die groben Linien schon noch stimmen aber es gab in der Zwischenzeit zumindest 5 Technologie Generationen und es hat sich so manches geaendert.

There have been lots of questions concerning the Tile based rendering technique used in all PowerVR product. Some competitors (both 3Dfx and Nvidia) of PowerVR keep saying that the technique doesn't work or will run into trouble when scenes get more complex.

Fuer 3dfx (RIP) war tiling der letzte Dreck bis kurz vor dem Untergang als sie Gigapixel aufkauften welche auch rein zufaellig eine tile based IMR Architektur hatten. 3dfx wurde samt Gigapixel von NVIDIA aufgekauft und den Kaugummi von ueberstopften Puffern hoere ich jetzt schon seit ueber 15 Jahren.

Der PowerVR ist zwar nicht bei weitem perfekt, noch ist IMG fehlerfrei eher das brutale Gegenteil. Jedoch sehe ich in den letzten 8-9 Jahren seit dem grossen ULP SoC boom keine Probleme mit deren GPUs. Ich sehe in den fuer die Dinger entwickelten Spiele auch keine proportional bescheidene Geometrie order irgendwelche merkwuerdigen "Anpassungen" (und bevor es jemand sagt IMG hat keine Entschuldigung fuer den windows Treiber Skandal).

Komischerweise hat SGX einen hw bug mit scissoring bzw. alpha tests (eigentlich eine Schande fuer einen TBDR). Intern bei IMG wird es elegant unter den Teppich gekehrt und in dev papers wird zwar nichts erwaehnt aber eine Alternative fuer scissoring vorgeschlagen. Trotz allem schlagen sich die Dinger alles andere als schlecht in GLB2.7 welches tonnenweise alpha tests hat.

Tut mir leid wenn mir jemand eine logische Erklaerung gibt die ich auch bei mehreren Seiten sicherstellen kann steck ich es gerne und sofort ein. Wenn aber jemand bissig wird nur weil ich ihm seinen Lieblings-IHV links angepinkelt habe ja da verhalte ich mich auch wie ein fanboy im Sandkasten.

Sonst zu Deinem Post oben, bei einem IMR verstehe ich simultane bzw. parallele Bearbeitung von vertex-, pixel shading, rasterizing. Wenn der framebuffer in den temporaeren framebuffer eines tile based IMR passt schoen und gut dann einfach single pass; im Gegenfall multi-pass wobei zwar diesmal vom ersten pass das binning bekannt ist, aber es werden weiterhin pixels und Geometrie parallel verarbeitet (mal verdammt grob illustriert denn ich hab auch mit einer Sprach-barriere zu kaempfen). Beim PowerVR ist pixel von vertex entkoppelt.

Bei MPs/multi-core configs jetzt wie im Vita sind es zwar 4 cores mit 4 raster units und 4 trisetups aber es kommt im besten Fall ein Tri/clock raus und nicht mehr eben weil der workload verteilt wird. Bei den 200MHz der Vita gibt es noch eine Geometrie-Bruecke namens Hydra die u.a. der hohen Geometrie-Effizienz hilft bei multi-core und taktet hoeher als der core. Eine Szene wird zuerst in macro tiles aufgeteilt und dann je nachdem wieviel freie resources jeder core hat auf jeden einzelnen verteilt. Es wird wohl nicht zu schwer sein zu raten was Hydra in dem Fall macht und wie sonst das Ganze verteilt wird. Ausser vielleicht der Frequenz fuer Hydra bezweifle ich dass die internen Prozesse bzw. das load balancing zwischen den cores transparent zum Entwickler sind.

Das oede "+" uebrigens nach dem SGX543MP4+ fuer das Vita ist hauptsaechlich texturing relativer Schnickschnack den SONY noch haben wollte und in Zusammenarbeit mit IMG dazugesteckt hat weil SGX544 zu dem Zeitpunkt noch nicht fertig war.

Mehr oder weniger alles was mir fuer die Vita GPU mal schnell eingefallen ist. Ich verstehe Sony immer noch nicht warum sie den Quark in die TV set top box gesteckt haben, womoeglich um ueberschuessige SoCs loszuwerden.

Je nachdem, wie stark man da noch weiter abspeckt, kann man am Ende auch unsere normalen Desktop-GPUs als tile based Renderer bezeichen.
(i) Framebuffer divided into tiles: check
(ii) geometry is binned to framebuffer tiles: check
(iii) ROPs work on onchip memory tile caches for increased bandwidth efficiency for blending and AA: check (zumindest bei AMD sind die sogar extra, bei nV ist das der L2)

Just my 2 cents.

Desktop-GPU machen das, um die Bandbreiteneffizienz zu erhöhen (das tut man selbst wenn die tile caches ständig in den VRAM geschrieben und neu gelesen werden müssen, die also ständig getrashed werden), aber auch als Mittel, um das Rastern und das Pixelbackend besser zu parallelisieren. Dreiecke, die in unterschiedlichen Screentiles liegen, können parallel gerastert werden (und man muß die Draw-Reihenfolge nicht mehr einhalten, weil sie nicht überlappen). Die Geometrie wird anhand der Screentiles in die sie fallen, auf die Rasterizer aufgeteilt (sowohl bei nV als auch bei AMD). Man "binned" also zwar im Prinzip in tiles (zumindest wird festgestellt, in welchem Tile das Dreieck liegt), sammelt aber die Geometrie vor dem Rastern nicht sondern macht direkt weiter.

Zweifellos; early Z ist ja grob vereinfacht auch nichts anderes als eine Art deferred rendering. Ist ja auch alles verdammt relativ da ein IMR mehr als oefters verzoegern wird und ein DR auch nicht alles und immer verzoegern wird (wenn ein TBDR in einen seltenen Engpass kommt wird es sich auch wie ein IMR verhalten muessen und ja in solch einem Fall wird es schon ziemlich weh tun). Prinzipiell gibt es aber schon immer noch wichtige Unterschiede wie z.B. wie Du selber erwaehnst dass ein IMR Geometrie so bearbeitet wie sie reinfliesst.

[del_4901]

Hier findet sich noch eine schoene Beschreibung wie ein TBDR arbeitet:
develop.scee.net/files/presentations/develop2011/PSVitaCodingKeynote.pdf

Tut mir leid wenn mir jemand eine logische Erklaerung gibt die ich auch bei mehreren Seiten sicherstellen kann steck ich es gerne und sofort ein. Wenn aber jemand bissig wird nur weil ich ihm seinen Lieblings-IHV links angepinkelt habe ja da verhalte ich mich auch wie ein fanboy im Sandkasten. Man sollte nicht von sich auf Andere schliessen.

[Ailuros]

Was soll mir SONY's marketing-Scheiss genau sagen dass nicht schon bekannt ist?


Man sollte nicht von sich auf Andere schliessen.

Da Du die Affaere nicht weiter aufklaerst um was es sich genau handelt kann man gutmuetig glauben dass Du es nicht darfst. In solch einem Fall ist es eher weisser so einen Teufelskreis ueberhaupt nicht zu beruehren.

Aber es ist trotz allem interessant dass Du Dich angesprochen gefuehlt hast. Bleibt abzusehen was die Zukunft bringt und im Fall wo ich falsch liege habe ich auch stets den Anstand es einzugestehen.