SIS deferred renderer ???

[Liszca]

ist der sis 330 ein deferred renderer ??? ??? ???

[silmarin]

:lol:

[ca | Blade-IV]

Originally posted by silmarin
:lol:

Was sagt uns dass ?

[silmarin]

editiert, weil sonst gleich jemand geheult hätte...

[Liszca]

dann sag doch einfach nichts! war mit defered... der fast z clear gemeint ???

[mapel110]

zumindest etwas in die gleiche richtung, liszca. aber um auf deine frage zu antworten.

NEIN

[aths]

Liszca,

seit einigen Tagen spammst du auffällig rum.

[MadManniMan]

was sagt uns das?

kommt her kinders, hiers lustig! liscza postet wieder lustige sachen *popcornrauskram*

:jump1: LISCZA!LISCZA! :jump1:

[mapel110]

vielleicht hat liszca ja frühlingsgefühle ;D sinnvolle postings von ihr waren in den letzten tagen wirklich selten. obwohl ich nicht beurteilen kann, ob das jemals der fall war.

stellt sich die frage, ob das bei frauen generell so ist, oder ob unsere liszca da einen spezialfall darstellt.
ist liszca vielleicht eine deferred rendered frau ??? ;D

[ca | Blade-IV]

Originally posted by MadManniMan
was sagt uns das?

kommt her kinders, hiers lustig! liscza postet wieder lustige sachen *popcornrauskram*

:jump1: LISCZA!LISCZA! :jump1:

biste du inem Liszca Fanclub ?? , der tread ihr ist wohl müll.... ;)

[MadManniMan]

Originally posted by ca | Blade-IV


biste du inem Liszca Fanclub ?? , der tread ihr ist wohl müll.... ;)

jaaa! auch ca | Blade-IV macht mit und postet wirres zeugsens!

:jump2: ca | Blade-IV ! ca | Blade-IV ! :jump2:

[Unregistered]

Hi

@ Liscza

Komm Mädel zeig wo der Hammer hängt. *bfg*
------------------------------------------
Laut www.tommti-systems.com wird in einen Satz diese Frage aufgeworfen und ein Link an diese Seite http://www.gzeasy.com/itnewsdetail.asp?nID=2342 verwiesen.

Wenn das Teil mit den Werten echt ein ähnliches TBR System hat na dann gute Nacht.
Allerdings kann ich kein chinesisch. *bfg*

Dürft aber eher ein Witz sein.

Gruss Labberlippe

[ca | Blade-IV]

Originally posted by MadManniMan


jaaa! auch ca | Blade-IV macht mit und postet wirres zeugsens!

:jump2: ca | Blade-IV ! ca | Blade-IV ! :jump2:

nein stimmt doch gar nicht.... der Thread IST Müll, das ist kein wirres Zeug.. ;)

[Unregistered]

Lol

Wäre genial wenn SIS mit einen TBR mit DX8.1 kommt.
Da würde Power VR die :O runterfallen.

Hehehe wäre ein herber Schlag. *bfg*
Aber ganz kann ich das nicht glauben.

Gruss Labberlippe

[Leonidas]

Steht zu bezweifeln. Der Chip ist mehr oder weniger offiziell angekündigt. Warum sollte SiS das wichtige Detail von allen verschweigen?


Nicht unmöglich - aber verdamt unwahrscheinlich.

[Unregistered]

Ihr hab doch alle keinen Dunst von der Sache. Da werde ich euch mal die Augen öffnen und frage nach der Übersetzung von "deferred": Es heißt doch so viel wie "verzögert". Na? Fällt der Groschen? Ist jetzt klar, warum der SIS so lahmarschig ist? - Der beste und erste deferred renderer am Markt war der virge von S3, der war kein 3- Beschleuniger, sondern ein 3d- Verzögerer. Weil man zwar gute Chips bei S3 baute, aber mit dem Marketing nicht so gut drauf war, wurde der Begriff "deferred renderer" erst viel später geprägt....

[Piffan]

Mist, nun habe ich schon wieder die Cookies verlegt und nun wird dieses tolle Post nicht gezählt

[Piffan]

Originally posted by Piffan
Mist, nun habe ich schon wieder die Cookies verlegt und nun wird dieses tolle Post nicht gezählt

Irrtum, nun sinds ja schon zwei :D

[nocturne]

Originally posted by Leonidas
Steht zu bezweifeln. Der Chip ist mehr oder weniger offiziell angekündigt. Warum sollte SiS das wichtige Detail von allen verschweigen?


Was soll daran so "wichtig" sein? Das ist ja kein "Feature", das für Spieleentwickler bzw. DirectX oder OpenGL-Software wichtig wäre, sondern nur eine andere interne Arbeitsweise. Und für die Anwender ist das erst recht irrelevant.

Wie der Chip INTERN arbeitet, kann uns doch egal sein.

"Das, was hinten rauskommt, zählt" ;)

[ActionNews]

Hmm....:o :
DAS meldet zumindest Tommti-Systems, aber simmen m,uss es ja noch lange nicht:
SiS 330 verwended Tile-based Rendering

Damit ist der SiS 330 der zweite GPU, welcher auf dieser Architektur aufbaut. Fast Z-Clear wird ebenso unterstützt.

Dabei verweisen sie auf folgende Seite: http://www.gzeasy.com/itnewsdetail.asp?nID=2342
Allerdings ist das eine asiatische Seite und viel erkennen kann ich nicht!

CU ActionNews

[nocturne]

Also ist es KEIN echter deferred renderer. Der bräuchte nämlich kein fast-z-clear. ;)

[Leonidas]

Originally posted by nocturne


Was soll daran so "wichtig" sein? Das ist ja kein "Feature", das für Spieleentwickler bzw. DirectX oder OpenGL-Software wichtig wäre, sondern nur eine andere interne Arbeitsweise. Und für die Anwender ist das erst recht irrelevant.

Wie der Chip INTERN arbeitet, kann uns doch egal sein.

"Das, was hinten rauskommt, zählt" ;)




:-)

Wenn der SiS 330 ein TB-Renderer ist, würde das bedeuten, daß man die Geschwindigkeits-Prognose um den Real-Faktor 1.7 erhöhen kann. Und DAS ist ein Unterschied.

[ActionNews]

Originally posted by nocturne

Also ist es KEIN echter deferred renderer. Der bräuchte nämlich kein fast-z-clear. ;)


Da sind wir ausnahmsweise eine Meinung! Wo kein Z-Buffer ist, kann auch kein Z-Buffer schnell gelöscht werden!

CU ActionNews

[Quasar]

Häh?

Und das Silizium, was sie auf der CeBit gezeigt haben, lief noch im SGI-Mode oder wie? Die Leistungsprognose steht aufgrund eines Benchmarks, der von SiS in Hannover gezeigt wurde. Da war die Geschwindigkeit in etwa im Bereich der GF4MX 440.

[Pirx]

Wenn das nicht stimmt hat sich Tommti aber übel in die Nesseln gesetzt:) (oder sein Systemdatum falsch eingestellt - 1.April?)

[Tigershark]

Also wenn der SiS330 ein TBRenderer wäre, dann hätte SiS das mit Sicherheit bei der Präsentation erwähnt, weil es ja doch einiges an Leistung bringt. Abegsehen davon schliesse ich mich der Meinung hier an : Ein TBRenderer braucht numal kein "Fast-Z Clear" ;)

[nocturne]

Dass ich das noch erleben darf, dass mir ActionNews und Tigershark mal zustimmen... ;)

Hey Pirx, wer ist das Mädel auf Deinem Logo?

[Pirx]

Das macht Altavista aus dem Satz:

GZeasy.com: SIS330 has reduces invalid exaggerates the technology? Is exaggerates (Tiled Based Rendering) based on the block type or Hierarchical Z? Îù series company: Yes, SIS330 has reduces invalid exaggerates the technology, reduces based on the block -like invalid exaggerates the algorithm.
:)

Ist auf jeden Fall ein Interview und TBR wird von GZeasy ins Spiel gebracht. Ich glaub da nicht dran.

@nocturne
Lexa-"Andromeda"-Doig:love2:

[mapel110]

auf inquirer gabs zu lesen, dass durch agp8x die performance um 10%ansteigt beim sis330. ist es möglich, dass an dem chip irgendwas neuartiges ist, dass die agp-bandbreite besser ausnutzt ?
ich meine, es wird schliesslich gefolgert, dass das zurückschalten auf agp4x einen geschwindigkeitsverlust von 10% bringt. das kann natürlich eine ausrede für sis sein, wenn der chip nicht mit den anderen dx8.1-boliden mithalten kann.

[Quasar]

Schön wär's ja, aber ehrlich gesagt glaube ich nicht dran. Wie soll das auch funktionieren? Mit AGPx8 hat man ca. 2GB/s die übertragen werden könnten. Dummerweise gibt's auch noch ein paar andere Komponenten, die Bandbreite haben wollen: CPU, PCI-Karten etc.pp..

In konstruierten Szenarien à la "BenMark" der den Dreiecksdurchsatz über den AGP misst, könnte man aber durchaus auch mehr als 10% Gewinn erreichen. In Anwendungen wird davon aber Null oder etwas, das sich Null asymptotisch annähert, ankommen.

[HOT]

AGP 8X bringt bei heutigen Realanwendungen noch keine Leistungsvorteile. SIS kann den AGP Bus auch nicht ausserhalb seiner Spezifikationen betreiben ;)
Der SIS330 ist kein deferred Renderer, soviel ist mal sicher. Hat das Teil eigentlich wirklich Z-Clear?

[Liszca]

ums mal klar zu stellen, mir ist schon klar das ein defered renderer kein fast z clear braucht, wollte nur wissen ob die ihn deferred renderer nennen weil er fast clear beherrscht!?

[Quasar]

Originally posted by HOT
Hat das Teil eigentlich wirklich Z-Clear?

Davon sollte man ausgehen... :lol:

[StefanV]

NEIN!
Ein Deffered Renderer ist der SIS330 nicht!

JA!
Der SIS330 ist ein TBR!

ABER:

TROTZ TBR ist er ein SGI Renderer ;)

TBR und SGI schließen sich nicht aus, nur Deffered und SGI schließen sich aus ;)

Interessant wirds erst dann, wenn man mit den Tiles arbeitet (z.B. für FSAA usw) ;)
Solange man die Tiles nicht weiter 'bearbeitet' ist TBR vollkommen uninteressant und bietet keine Vorteile.

Die Frage ist also:

WAS macht der SIS330 mit den Tiles??

Setzt er sie nur zussammen oder werden da informationen hinzugefügt/entfernt??

[GloomY]

Wie in einem anderen Thread (Technologieforum?) bereits gesagt:

Tile Base Rendering kann auch mit "normalem" Z-Buffer geschehen.
Oder anders ausgedrückt: TBR und HSR sind zwei (fast) voneinander unabhängige Dinge. Durch TBR wird HSR erst möglich, es ist aber kein Muss für einen TBR.

Das Rendering kann durchaus (wie Stephan Payne richtig erwähnte) als SGI Renderer funktionieren (also mit normalem Z-Buffer, Poligon für Poligon).

Allerdings kann man um die Bezeichnung "Deferred Renderer" streiten. Einerseits werden wie bei einem TBR üblich alle Poligone erst einmal in einer Display List gesammelt (und damit das Rendering geringfügig verzögert), andererseits funktioniert das Rendering so wie bei einem SGI-Renderer (also sofort).

-> Leute, erkennt den Unterschied zwischen TBR mit und ohne HSR...

[Modulor]

Originally posted by Stefan Payne

...
JA!
Der SIS330 ist ein TBR!
...


Hast Du verläßliche Quellen oder kann man das irgendwo im Netz nachlesen? Bis auf diese unverständliche Übersetzung von GZeasy habe ich davon noch von keiner Seite was gehört...

@Liszca
Als "deferred renderer" werden imo nur Chips bezeichnet, die zum Zeitpunkt der *Texturierung* bereits alle Daten der Szene vorliegen haben, im Falle von KYRO mittels einer display list (weswegen PowerVR auch selber von einem "display list renderer" spricht.

Wenn bei der SIS 33x Familie wirklich tile based rendering ohne deferred texturing verwendet werden soll, frage ich mich ebenso wie Stefan wozu dann der Aufwand dient ??

Egal, jeder neue nicht-IMR ist eine willkommene Abwechslung :D !

[GloomY]

Originally posted by Stefan Payne
Interessant wirds erst dann, wenn man mit den Tiles arbeitet (z.B. für FSAA usw) ;)
Solange man die Tiles nicht weiter 'bearbeitet' ist TBR vollkommen uninteressant und bietet keine Vorteile.Hmm, doch.
Da man die Poligone immer nur Kachelweise rendert, kann man z.B. den Z-Buffer als kleinen Cache auf dem Grafikchip implementieren und so sehr viel Speicherbandbreite sparen. Denn nach dem Rendern einer Kachel muss man den Inhalt des Z-Buffers nicht mehr im Graka-RAM abspeichern, da er ja für diese Kachel definitiv nicht mehr gebraucht wird (man hat ja bereits alle in dieser Kachel befindlichen Poligone gerendert).

[Modulor]

Hey, Du hast ja auch `nen KYRO II :love1: !!

[StefanV]

Originally posted by Modulor
Hast Du verläßliche Quellen oder kann man das irgendwo im Netz nachlesen? Bis auf diese unverständliche Übersetzung von GZeasy habe ich davon noch von keiner Seite was gehört...

Ja, irgendwo ein englisches Interview mit SIS...

Da wurde gesagt, daß der 330 ein TBR ist...

[StefanV]

Originally posted by GloomY
Hmm, doch.
Da man die Poligone immer nur Kachelweise rendert, kann man z.B. den Z-Buffer als kleinen Cache auf dem Grafikchip implementieren und so sehr viel Speicherbandbreite sparen. Denn nach dem Rendern einer Kachel muss man den Inhalt des Z-Buffers nicht mehr im Graka-RAM abspeichern, da er ja für diese Kachel definitiv nicht mehr gebraucht wird (man hat ja bereits alle in dieser Kachel befindlichen Poligone gerendert).

Gut, damit hast du recht.

Aber IMHO ist dafür der Aufwand zu groß...

Es sei denn man hat einen TBR wegen FSAA gemacht...

[GloomY]

Originally posted by Stefan Payne
Aber IMHO ist dafür der Aufwand zu groß...Darüber müsste man mal ausführlich nachdenken. Immerhin wird der "Hauptverschwender" von Speicherbandbreite (Z-Buffer) mit dieser Methode eingespart...
Originally posted by Stefan Payne
Es sei denn man hat einen TBR wegen FSAA gemacht... Yep, dann lohnt es sich ziemlich sicher.

[MadManniMan]

leutz, ratet mal, woher die powerVR serien(schönes wort) ihre ganze bandbreite hernehmen. am deferred rendering liegst nicht, daher full ack @glühmchen(schön, dich mal wieder zu sehen)

[StefanV]

Originally posted by GloomY
Darüber müsste man mal ausführlich nachdenken. Immerhin wird der "Hauptverschwender" von Speicherbandbreite (Z-Buffer) mit dieser Methode eingespart...
Yep, dann lohnt es sich ziemlich sicher.

Hab nochmal drüber nachgedacht...

Es spart Bandbreite, da einige Speicherzugriffe entfallen...
Z Puffer ist immer noch nötig...
Also wenn etwas mehrmals geschrieben werden soll...

Irgendwie hab ich das Gefühl, daß es vorraussetzung für 'FSAA 4 Free' ist...
Allerdings ist die Füllrate dann das problem ;)


@MadManni
Deffered Rendering setzt aber TBR vorraus ;)

Sonst kann man sich die Ganze Aktion sparen und gleich mehrere MB eDRAM auf die Karte pressen ;)

Erst durch TBR UND Deffered Rendering (eliminierung ALLER nicht benötigten Informationen) erreicht der Chip seine performance...

Allein durch TBR nicht ;)

[ActionNews]

Originally posted by GloomY
Darüber müsste man mal ausführlich nachdenken. Immerhin wird der "Hauptverschwender" von Speicherbandbreite (Z-Buffer) mit dieser Methode eingespart...
(...)

Aber das ist doch genau das wie es bei den PowerVR-Chips auch funktioniert! Die Z-Werte werden in einem Cache auf dem Chip gespeichert! Aber zusätzlich können die Z-Werte auch im Speicher abgelegt werden, da manche Spiele damit Probleme hatten, weil dieer "Z-Buffer" sonst fehlt! Was man dann ja auch in den Treibereinstellungen umstellen kann!
Oder habe ich das jetzt falsch verstanden?

CU ActionNews

[ow]

Originally posted by GloomY
Wie in einem anderen Thread (Technologieforum?) bereits gesagt:

Tile Base Rendering kann auch mit "normalem" Z-Buffer geschehen.
Oder anders ausgedrückt: TBR und HSR sind zwei (fast) voneinander unabhängige Dinge. Durch TBR wird HSR erst möglich, es ist aber kein Muss für einen TBR.

Das Rendering kann durchaus (wie Stephan Payne richtig erwähnte) als SGI Renderer funktionieren (also mit normalem Z-Buffer, Poligon für Poligon).



Also TBR ohne HSR duerfte das mit Abstand sinnloseste sein, was es gibt.

[ow]

Originally posted by GloomY
Darüber müsste man mal ausführlich nachdenken. Immerhin wird der "Hauptverschwender" von Speicherbandbreite (Z-Buffer) mit dieser Methode eingespart...
Yep, dann lohnt es sich ziemlich sicher.

a) ist die durch Z-Buffer benutzte Speicherbandbreite gering, also von "Hauptverschwender" keine Spur

b) Wo soll bei FSAA der Vorteil liegen?

[ow]

Originally posted by MadManniMan
leutz, ratet mal, woher die powerVR serien(schönes wort) ihre ganze bandbreite hernehmen. am deferred rendering liegst nicht, daher full ack @glühmchen(schön, dich mal wieder zu sehen)


Unsinn!

[StefanV]

Originally posted by ow
Also TBR ohne HSR duerfte das mit Abstand sinnloseste sein, was es gibt.

Nicht unbedingt ;)

Durch TBR lassen sich ja einige Speicherzugriffe Sparen, die man in einen kleinen internen Cache verlagern könnte.

Was insbesondere für FSAA nicht schlecht ist, aber dazu gibt es noch keine Aussage von SIS...

[MadManniMan]

huppala, da hab ich mir grad in das eigene fleisch geschnitten...

sorry, ow, hast recht ;)

[ow]

Originally posted by Stefan Payne

Nicht unbedingt ;)

Durch TBR lassen sich ja einige Speicherzugriffe Sparen, die man in einen kleinen internen Cache verlagern könnte.



Inwiefern? Was soll da wie gespart werden?

[ow]

Originally posted by MadManniMan
huppala, da hab ich mir grad in das eigene fleisch geschnitten...

sorry, ow, hast recht ;)

kein Problem:)

[MadManniMan]

hey mann, jetzt fällt mir mal auf, was für ein blödsinniger stuß tbr ohne deferred rendering ist...

[ow]

:D

Genau meine Meinung.

Aber vielleicht hat ja hier jemand noch aussagekraeftige Argumente

Ich seh derzeit keinen Sinn drin, erst mal alle Polygone zu sammeln und dann konventionell zu rendern, dieses aber tile-weise zu tun.

Ist doch Mehrarbeit fuer den Chip, zB. Zerlegung der Polygone, die mehrere Tiles ueberdecken,...

[HOT]

Diese Technik ist in der Tat nur für HSR Sinnvoll. Da ist es egal, ob dies nur für den Z-Buffer oder für den ganzen Renderingprozess gilt. Man arbeitet ja auch nur Tile Based, weil da die Anzahl der hintereinanderliegenden Objekten wesentlich leichter zu checken ist, und weil man so von einem internen Peffer profitieren kann und Speicherbandbreite einspart, aber das ist nur ein netter Nebeneffekt.
Deseweiteren ist nunoch Singlebuffering notwendig, was aber genauso ein netter Nebeneffekt ist. Wenn man kein HSR durchführt lohnt die Mühe für TBR nicht.
Andersrum kann HSR nicht ohne TBR funktionieren, weil der Rechenaufwand einfach zu hoch wäre.

[ow]

Ja so sehe ich das auch.


btw:
Wie muss man sich eigentlich Single Buffering auf TBRs vorstellen?

Muesste man da nicht ebenfalls dem Renderprozess "zuschauen" koennen (wie bei IM Renderern), da ja der Framebuffer, in den die fertigen Tiles geschrieben werden, gleichzeitig vom RAMDAC ausgelesen wird?

[Modulor]

Originally posted by ow

...
btw:
Wie muss man sich eigentlich Single Buffering auf TBRs vorstellen?
...


Jedes 32x16 pixel große tile, das im on-chip framebuffer komplett vorliegt wird in den frontbuffer geschrieben. Dadurch daß die komplette Szene im Chip bereits vorliegt bedarf es nur wenig mehr Zeit bis auch die anderen tiles in den frontbuffer geschrieben werden.
Singlebuffering kann zu Darstellungsfehlern führen - ich habe aber bislang noch keine bemerkt, die darin begründet liegen.


...
Muesste man da nicht ebenfalls dem Renderprozess "zuschauen" koennen (wie bei IM Renderern), da ja der Framebuffer, in den die fertigen Tiles geschrieben werden, gleichzeitig vom RAMDAC ausgelesen wird?

Wenn man sich diesen Vorgang mal bewußt muß man doch sagen, daß PowerVR diese Prozesse im KYRO nahezu perfekt im Griff hat: man müßte theoretisch den Bildaufbau beim singlebuffering sehen können, aber ich weiß nicht, mit wieviel MHz KYRO dann laufen müßte - 0,5 oder 1 vielleicht :D (die MBX-Demo auf der CeBIT lief mit 14 MHz!).

[Xmas]

Wer die Single-Buffering-Artefakte nicht sieht, sieht auch kein Tearing bei deaktiviertem VSync. Und andersrum: wer Tearing sieht, sieht die SB-Artefakte erst recht, weil sie deutlicher sind.

[ow]

Fuehrt single buffering nicht IMMER zu Artefakten?
Der RAMDAC kann ja praktisch nie ein komplettes Bild aus dem Frontbuffer auslesen.

[GloomY]

Originally posted by ActionNews
Aber das ist doch genau das wie es bei den PowerVR-Chips auch funktioniert! Die Z-Werte werden in einem Cache auf dem Chip gespeichert!Nein, imho haben die PowerVR-Chips gar keinen Z-Buffer (auch nicht auf dem Chip), da sie ja eh' nur das rendern, was sichbar ist.
Originally posted by ActionNews
Aber zusätzlich können die Z-Werte auch im Speicher abgelegt werden, da manche Spiele damit Probleme hatten, weil dieer "Z-Buffer" sonst fehlt! Was man dann ja auch in den Treibereinstellungen umstellen kann!
Oder habe ich das jetzt falsch verstanden?
CU ActionNews Das ist in der Tat eine zusätzliche Option, die dann aber leistungsmäßig eher nicht zu empfehlen ist.

Oder hab' ich da was falsch verstanden?

[GloomY]

Originally posted by ow
Also TBR ohne HSR duerfte das mit Abstand sinnloseste sein, was es gibt. Das sehe ich anders.
Originally posted by ow
a) ist die durch Z-Buffer benutzte Speicherbandbreite gering, also von "Hauptverschwender" keine Spur

b) Wo soll bei FSAA der Vorteil liegen? zu a)
Was ist dann deiner Meinung nach der "Hauptverschwender" von Speicherbandbreite? ??? Der RAMDAC isses sicher nicht, der braucht bei 1024x768x32 und 100 Hz gerade mal 300 MB/Sek.
Die Texturzugriffe sind heuzutage dank Texturecompression auch deutlich geringer als Backbuffer und/oder Z-Buffer.
Und was diese beiden betrifft:
Beide sind gleich groß (32Bit pro Pixel bzw. 24Bit plus 8 Bit Stencil).
Bei einem SGI-Renderer wird bei jedem Pixel der vorherige Wert des Z-Buffers gelesen. Dann gibt es zwei Möglichkeiten: Ist der Pixel sichtbar, dann wird sowohl der neue Farbwert in den Framebuffer geschrieben, als auch der neue Z-Wert.
Zusammen: 1 Z-Read, 1 Z-Write, 1 Backbuffer-Write. Somit braucht man mehr Speicherbandbreite pro Pixel für den Z-Buffer als für den Back-Buffer.
Zweite Möglichkeit: Pixel ist nicht sichtbar: Dann war's das.
Zusammen: 1 Z-Read

Beim Flippen der beiden Framebuffer werden diese natürlich nicht kopiert, sondern diese bleiben an ihren Plätzen und der RAMDAC benutzt den Backbuffer und der Grafikchip rendert und den Frontbuffer. Somit braucht man keine Speicherbandbreite für das Flippen.

-> Der Z-Buffer braucht immer mehr Speicherbandbreite als der Backbuffer.

zu b)
Ganz einfach: Das Multi- oder Supersampling wird auf dem Chip gemacht, ohne dass dafür der Graka-RAM benutzt wird. Damit wird bei FSAA Null Speicherbandbreite verbraucht (nur Füllrate).
Ein Tiler kann FSAA bei genügend Füllrate also quasie umsonst ohne Perpormanceverlust realisieren.

Originally posted by ow
Inwiefern? Was soll da wie gespart werden? Wie oben bereits erwähnt:
Der Z-Buffer liegt nicht mehr im Graka-RAM sondern ist dank seiner geringen Größe jetzt in einem Cache auf dem Chip gespeichert. (Das ist eben dadurch möglich, daß man immer nur eine Kachel, also einen winzigen Bildschirmteil betrachtet).
Da man nach dem Rendern der Kachel den Wert im Normalfall nicht mehr braucht (man hat ja bereits alle in dieser Kachel befindlichen Poligone gerendert), muss man ihn auch nicht mehr im Graka-RAM speichern. -> Mit Hilfe dieses Caches braucht man Null Speicherbandbreite für den Z-buffer
Originally posted by ow
Ich seh derzeit keinen Sinn drin, erst mal alle Polygone zu sammeln und dann konventionell zu rendern, dieses aber tile-weise zu tun.Siehe oben.

[GloomY]

Originally posted by ow
Fuehrt single buffering nicht IMMER zu Artefakten?Ja und nein.
Wenn du Tearing als Artefakt siehst, dann: ja.
Wenn man das als nicht so schlimm ansieht (im Gegensatz zu durchsichtigen Wänden, die bei IR entstehen können ;) ), dann eben nicht.

Der Vorteil des TBR ist, daß er weiss, welche Poligone wo im Bild auftauchen. Wenn er ein Tile gerendert hat, dann kommt in diesem Bildschirmabschnitt garantiert nichts mehr hinein. Daher wird auch nur das letztendlich korrekt gerenderte Bild in den Framebuffer geschrieben.
Bei einem IR sieht das ganz anders aus:
Wenn man da ein Poligon rendert, heisst das noch lange nicht, dass es auch letztendlich sichtbar ist. Man schreibt halt mal einen Farbwert hinein, ob dieser durch ein später gerendertes Poligon noch überdeckt wird, ist nicht vorherzusagen.
Wenn man nun nur einen Framebuffer benutzt, d.h. rendert dort hinein und der RAMDAC liest gleichzeitig davon, kann es eben durchaus vorkommen, daß der RAMDAC einen Farbwert liest, der letztendlich gar nicht sichtbar wäre (weil er später noch von einem anderem Poligon überdeckt wird).

Bei einem TBR kann soetwas eben nicht passieren, da er immer nur das letztendlich sichtbare Bild in den Framebuffer schreibt. Das schlimmste was passieren kann, ist Tearing.

[GloomY]

Originally posted by MadManniMan
huppala, da hab ich mir grad in das eigene fleisch geschnitten...

sorry, ow, hast recht ;) Woher kommt dieser plötzliche Meinungsumschwung ?

btw: Du lebst ja auch noch ;) Schön dich mal wieder zu sehen =)

[ow]

Originally posted by GloomY
Nein, imho haben die PowerVR-Chips gar keinen Z-Buffer (auch nicht auf dem Chip), da sie ja eh' nur das rendern, was sichbar ist.



Sehr viel scheinst du von der Funktionsweise des TBR wohl nicht zu verstehen. Anhand welcher Werte glaubst du denn kann der Chip entscheiden, was sichtbar ist und was nicht?

[GloomY]

Originally posted by ow


Sehr viel scheinst du von der Funktionsweise des TBR wohl nicht zu verstehen. Anhand welcher Werte glaubst du denn kann der Chip entscheiden, was sichtbar ist und was nicht? Anscheinend mehr als du...

Bei den PowerVR-Chips findet vor dem Rendering ein Verfahren statt, das man Hidden surface Removal (HSR) nennt. Dabei werden die nicht sichtbaren Dreicke aus der Display-List entfernt.

Beim Rendern muss der Chip dann nicht mehr entscheiden, was denn nun sichtbar ist, denn Alles was übrig geblieben ist, ist sichtbar (mit Ausbnahme von Halb-durchsichtigen Dreicken).

[StefanV]

@gloomy

Hier wird kein Tilebased Deffered Rendering genutzt!!

Sondern einfach nur TBR auf einem SGI Renderer...

Einen Z-Buffer gibts weiterhin...

[loewe]

Originally posted by GloomY
Anscheinend mehr als du...

Bei den PowerVR-Chips findet [B]vor dem Rendering ein Verfahren statt, das man Hidden surface Removal (HSR) nennt. Dabei werden die nicht sichtbaren Dreicke aus der Display-List entfernt.


So ein Quatsch!

Für ein Tile verhält sich der PowerVR Chip genauso wie ein IR, da gibt es grundsätzlich kaum Unterschiede.
Der Tiefentest und damit die Sichtbarkeitsprüfung für alle Dreiecke eines Tiles erfolgen je Pixel auf der Basis von z Werten, die eben nur im Chip verwendet werden. Nach der Abarbeitung einer Zeile (32 Pixel parallel) wird der "z-buffer" für die nächste Zeile verwendet, die alten Werte werden ja nicht mehr gebraucht.

[GloomY]

Originally posted by loewe


So ein Quatsch!

Für ein Tile verhält sich der PowerVR Chip genauso wie ein IR, da gibt es grundsätzlich kaum Unterschiede.
Der Tiefentest und damit die Sichtbarkeitsprüfung für alle Dreiecke eines Tiles erfolgen je Pixel auf der Basis von z Werten, die eben nur im Chip verwendet werden. Nach der Abarbeitung einer Zeile (32 Pixel parallel) wird der "z-buffer" für die nächste Zeile verwendet, die alten Werte werden ja nicht mehr gebraucht.
Und wo ist jetzt da der Widerspruch zu dem, was ich geschrieben habe?
Originally posted by Stefan Payne
@gloomy

Hier wird kein Tilebased Deffered Rendering genutzt!!

Sondern einfach nur TBR auf einem SGI Renderer...

Einen Z-Buffer gibts weiterhin...
Hier (=beim SIS) schon, aber nicht beim Kyro

edit: Verbesserung: Der Kyro benutzt einen winzigen Buffer beim HSR. Das passiert aber vor dem Rendering (=Bestimmen der Farbwerte der Pixel). Und darum ging es ja: Beim Rendern wird beim Kyro kein Z-Buffer gebraucht...

[MadManniMan]

nahmd glühmchen!

naja, schau noch mal meine FA durch, da siehste bestätigt, daß das nur vorteilhaft für das raycasting ist... ;)

[ow]

Originally posted by GloomY
Und wo ist jetzt da der Widerspruch zu dem, was ich geschrieben habe?



"Bei den PowerVR-Chips findet vor dem Rendering ein Verfahren statt, das man Hidden surface Removal (HSR) nennt. Dabei werden die nicht sichtbaren Dreicke aus der Display-List entfernt."

Das ist Quatsch.

"Nein, imho haben die PowerVR-Chips gar keinen Z-Buffer (auch nicht auf dem Chip)"

Und das auch.

[GloomY]

Originally posted by ow


"Bei den PowerVR-Chips findet vor dem Rendering ein Verfahren statt, das man Hidden surface Removal (HSR) nennt. Dabei werden die nicht sichtbaren Dreicke aus der Display-List entfernt."

Das ist Quatsch.Soviel hat mir Loewe auch schon gesagt.
Eine Begründung wäre zumindest auch hier sehr hilfreich...
Originally posted by ow
"Nein, imho haben die PowerVR-Chips gar keinen Z-Buffer (auch nicht auf dem Chip)"

Und das auch. Siehe oben...

[Legolas]

Originally posted by GloomY
Soviel hat mir Loewe auch schon gesagt.
Eine Begründung wäre zumindest auch hier sehr hilfreich...


Im HSR der Kyros werden keine Dreiecke aus der Displaylist gestrichen. Es wird nur für jedes Pixel ermittelt, welches Dreieck vorne liegt.

[ow]

Genau so ist es.

Allerdings ist der Begriff HSR da schon etwas missvertstaendlich, da eben nix "removed" wird.
(Es wird uebrigens auch nicht sortiert, wie man immer wieder liest).

[HOT]

Nein, es wird nur an der Stelle des Pixels nach dem Raycasting ein Pointer gesetzt, ab der Stelle, wo nicht mehr gerendert werden soll, mehr nicht. Diese Pointer werden zwischengeseichert - in eine Art Z-Buffer, also im Tilebuffer.
Danach wird ganz normal bis zur Stelle dieses Pointers gerendert.
SIS hat bisher diese Raycastingengine nicht, oder besser nicht fertig, sodass aber mit dem SIS330 schon eine gute Grundlage für einen deferred Renderer in der nächsten Entwicklungsstufe gelegt wurde.
Es ist ja eigentlich unerheblich, wie genau dieser Chip nun intern funktioniert, er unterscheidet sich (also das Ergebnis) nicht von den anderen üblichen SGI Renderen auf dem Markt.
Übrigens ist es für T&L absolut unerheblich, ob das ein TBR oder SGI Renderer ist, die Geometriedaten müssen so oder so im GrafikRAM zwischengepuffert werden - das müssen sie ja auch, wenn die Daten direkt von der CPU kommen.
Erst mit dem Displacementmapping ist es möglich Einfluss auf die Geometrie vom Renderingprozess aus zu nehmen, wie das funktionieren soll, fragen wir am besten Matrox :D

Ach ja, an die Kyrobesitzer: ist euch schonmal irgendeine Art von Tearing in Q3 oder Voyager EF aufgefallen?

[GloomY]

Hmm, dazu heisst es auf:
http://www.tilebase.de/frames/faq01.html
(ziemlich weit unten)

"Jetzt nimmt er jedes Pixel aus jedem tile und überprüft ob es überhaupt sichtbar ist. Wenn ja wird es berechnet, wenn nicht löscht der KYRO das Pixel aus seinem 'Gedächtnis' - der 'Display List' - und kümmert sich nicht weiter darum."

In wie fern ist das jetzt richtig oder falsch?

edit:
Ich glaub' ich hab's: Es wird auf Pixelbasis und nicht auf Dreicksbasis der Vergleich gemacht...

Ok, dann hab' ich das halt falsch verstanden. Mein Fehler...

[GloomY]

Originally posted by HOT
Ach ja, an die Kyrobesitzer: ist euch schonmal irgendeine Art von Tearing in Q3 oder Voyager EF aufgefallen? Du meinst mit Single-Buffering?

Bisher eigentlich nicht (ich benutze grundsätzlich singlebuffering unter OpenGL). Aber ich hab' auch nicht all zu sehr darauf geachtet.
Außerdem hat man während des zockens sein Augenmerk eher auf anderen Sachen...

[ow]

Wieso Single-Buffering?

Hat doch keine Vorteile gegenueber Double Buffering, oder?

[GloomY]

Originally posted by ow
Wieso Single-Buffering?

Hat doch keine Vorteile gegenueber Double Buffering, oder? Naja, man kann sich halt den backbuffer sparen ;)
Das sind bei 1024x768x32 3MB, die man dann mehr zur Verfügung hat.

[HOT]

Die Kyro Treiber stelen unter sämtlichen Quake3-Engine Spielen automatisch singlebuffering ein.
Ich hab eigentlich nie sowas wie tearing feststellen können.

[HOT]

Originally posted by GloomY
Hmm, dazu heisst es auf:
http://www.tilebase.de/frames/faq01.html
(ziemlich weit unten)

"Jetzt nimmt er jedes Pixel aus jedem tile und überprüft ob es überhaupt sichtbar ist. Wenn ja wird es berechnet, wenn nicht löscht der KYRO das Pixel aus seinem 'Gedächtnis' - der 'Display List' - und kümmert sich nicht weiter darum."

In wie fern ist das jetzt richtig oder falsch?

edit:
Ich glaub' ich hab's: Es wird auf Pixelbasis und nicht auf Dreicksbasis der Vergleich gemacht...

Ok, dann hab' ich das halt falsch verstanden. Mein Fehler...

Ist durchaus möglich, dass die Polyone ab dem Pointer "gelöscht" werden. Das wäre eine sehr einfache Möglichkeit, HSR durchzuführen.
Dummerweise kommt man nicht mehr auf den Artikel auf 3DConcept, dort steht alles sehr genau.

[Unregistered]

Originally posted by GloomY
Naja, man kann sich halt den backbuffer sparen ;)
Das sind bei 1024x768x32 3MB, die man dann mehr zur Verfügung hat.


Naja, 3MB. Ist ja nicht soviel. Immerhin hat mein Kyro1 ja 64MB RAM.:)

[ow]

Originally posted by HOT
Die Kyro Treiber stelen unter sämtlichen Quake3-Engine Spielen automatisch singlebuffering ein.
Ich hab eigentlich nie sowas wie tearing feststellen können.

also das mit den SB muss ich erst noch testen

aber das Tearing unter Q3 u.a. ist mir sofort aufgefallen.
Sieht naemlich "schlechter" aus als das Tearing mit meiner MX und der Radeon.

[GloomY]

Originally posted by HOT
Ist durchaus möglich, dass die Polyone ab dem Pointer "gelöscht" werden. Das wäre eine sehr einfache Möglichkeit, HSR durchzuführen.
Dummerweise kommt man nicht mehr auf den Artikel auf 3DConcept, dort steht alles sehr genau. http://www.3dconcept.ch/reviews/3dprophet4500/6.htm

"Für jedes Pixel der Kachel wird ein solcher Sichtstrahl in die Szene geschickt und so für jedes Pixel das erste sichtbare Dreieck bestimmt, indem der Abstand zwischen Startpunkt des Strahls und dem ersten Schnittpunkt festgehalten wird. Dieser Wert entspricht weitgehend dem gewohnten Z-Wert, liegt allerdings nicht auf einer zuvor definierten virtuellen Achse, sondern auf dem Sehstrahl. Der KYRO besitzt einen OnChip-Z-Buffer, in dem dieser ermittelte Tiefen-Wert abgelegt wird. Der Buffer ist exakt so groß gewählt, dass sämtliche Tiefenwerte einer Kachel (512 Stück) mit 32bit Genauigkeit abgelegt werden können (2 KB). Da jeweils eine Kachel komplett fertig berechnet wird, bevor mit dem nächsten Bildelement begonnen wird, kann sich der KYRO einen externen z-Buffer sparen und benötigt dadurch weniger Speicherbandbreite als traditionelle 3D-Beschleuniger. Um volle Spielekompatibilität zu erreichen, kann der interne Z-Puffer nach erfolgter Kachelberechnung am Ende doch im Grafikspeicher abgelegt werden oder gar direkt die Z-Werte während der Berechnung abgelegt werden, nötigt ist dies jedoch selten."

Ok, überzeugt. Der Kyro hat also einen OnChip Z-Buffer mit 2 kB Größe.

[HOT]

unglaubliche 2kb :D
Wie gesagt, er muss ja nur Pointer für einen Tile speichern.

[Modulor]

Ja,das ist es was mich vor einem Jahr am KYRO so dermaßen fasziniert hat (und nach wie vor fasziniert!) - das Konzept ist ziemlich genial...*wieder mal schwärm*

Zum hier behandelten Thema "Display List" schreibt PowerVR in seinem White Paper:
"... This allows a display list system to process each screen pixel individually and independently. Therefore, a display list renderer can be envisaged as a pixel processor, whilst an immediate renderer is a polygon processor."

Zum on-chip Z-Buffer heißt es:
"Display list processors carry out the depth comparison for each pixel as the initial part of their rendering pipeline. This depth sorting, or hidden surface removal (HSR), is only done once for each pixel and can therefore take place in a small on-chip Z buffer..." (wie klein der wirklich ist wissen wir ja jetzt :D)

Alles nachzulesen in einem der vielen PowerVR White Papers auf http://www.pvrdev.com/doc/idx/whitepapers.htm

[GloomY]

=)

Um mal wieder zum Theam zurückzukommen:
SIS mit seinem Tile- und SGI-Renderer

Hätte folgende Vorteile:

Durch Implementation von 2 Caches für Z- und Framebuffer (die jeweils 32x16x32bit=2kb Cache benötigen, also 32768 Bits insgesamt und damit bei herkömmlichem SRAM Cache gerade mal 131072 Transistoren benötigen) kann man sämtliche Z-Buffer-Zugriffe auf Null reduzieren.
Wie schon weiter oben aufgezeigt, ist dies der größte Anteil der verbrauchten Speicherbandbreite. Allein deshalb würde sich solch' ein TBR lohnen.

Zusätzlich dazu kann man alles andere in einem Pass rendern. Und das gilt auch für transparente Dreicke, für die ein IR IMMER mehrere Passes braucht (da hilft auch kein Loopback einer GF3 oder GF4).
Und wenn ich gerade bei Transparenzeffekten bin: Hier (http://www.3dconcept.ch/cgi-bin/showarchiv.cgi?show=1861) wird dazu deutlich Stellung bezogen:
"Die besonders für das Benchmarking von Grafikkarten beliebte Demo001-Sequenz aus Quake III Arena verfügt gemäss diesen Messungen über einen durchschnittlichen Overdraw von 3,83. [...] Wichtig dabei ist jedoch, dass der grösste Teil dieses Overdraws "produktiver" Overdraw ist, d.h. aus Transparenzeffekten entstanden ist."

Der Vorteil des SIS, alles in einem Pass zu rendern würde also durchaus noch einmal ein großes Stück Speicherbandbreite einsparen.

Dagegen steht der Aufwand, der durch das Anlegen der Display-List entsteht. Diese verbraucht natürlich auch noch etwas Platz im Graka-RAM, den man aber durch den Wegfall des Z-Buffers im Grafikspeicher wiederum einsparen kann.
Der Cache braucht wie oben berechnet 131072 Transistoren, was in Anbetracht heutiger Chip-Größen (GF3: 57000000, GF4: 63000000) eher nebensächlich erscheint...

btw: Bei allen Rechnungen bin ich von einer Tile-Größe von 32x16 Pixeln ausgegangen.

[loewe]

@ow
Danke!

Aber doch noch mal zum Thema.
Welchen Sinn sollte ein TBR ohne Displayliste machen? Ein deferred Renderer muss kein TBR sein, aber nur als TBR macht er Sinn und kann seinen Vorteil ausspielen. Ist hier eigentlich schon zur genüge begründet worden.

Ein IR auf Basis von Tiles?
Der IR erhält ein Polygon und rendert dieses. Dabei wird der z-Buffer geschrieben um späteren Polygonen die Möglichkeit zu geben, die bisher vorhandenen Pixel überschreiben zu können.
Mit Tiles müsste doch jetzt erstmal getestet werden in welchem Tile das Polygon liegt oder eben in welchen. Jetzt wird das Polygon entsprechend aufgeteilt falls notwendig und dann wie weiter abgearbeitet? Jetzt kommt das nächste Polygon und liegt aber in ganz anderen Tiles und erst das übernächste wieder in dem von eben. Wo bleibt denn jetzt solange die Tiefeninformation, es gibt doche keinen z-Buffer oder doch? Wann ist das Tile denn endgültig fertig, da es keine Displayliste gibt ist das Ende ja nicht bekannt?!

:)

[GloomY]

Originally posted by loewe
Aber doch noch mal zum Thema.
Welchen Sinn sollte ein TBR ohne Displayliste machen?Ich glaube, du hast da was überlesen ;)
Originally posted by GloomY
Dagegen steht der Aufwand, der durch das Anlegen der Display-List entsteht.Eine TBR ohne Display List wäre - wie von dir richtig erwähnt - Schwachsinn.Originally posted by loewe
Ein IR auf Basis von Tiles?
Der IR erhält ein Polygon und rendert dieses. Dabei wird der z-Buffer geschrieben um späteren Polygonen die Möglichkeit zu geben, die bisher vorhandenen Pixel überschreiben zu können.
Mit Tiles müsste doch jetzt erstmal getestet werden in welchem Tile das Polygon liegt oder eben in welchen. Jetzt wird das Polygon entsprechend aufgeteilt falls notwendig und dann wie weiter abgearbeitet? Jetzt kommt das nächste Polygon und liegt aber in ganz anderen Tiles und erst das übernächste wieder in dem von eben. Wo bleibt denn jetzt solange die Tiefeninformation, es gibt doche keinen z-Buffer oder doch? Wann ist das Tile denn endgültig fertig, da es keine Displayliste gibt ist das Ende ja nicht bekannt?!Also hier liegen mehrere Missverständnisse vor.

Ein Z-Buffer ist vorhanden (auf dem On-Chip-Cache) aber nicht im Graka-RAM.

Es handelt sich nicht um einen IR in dem Sinne, daß er sofort die einzelnen Dreiecke rendert.
Hier schaut er sich erst an, in welchen Tiles die einzelnen Dreicke liegen und sortiert diese dann in die Display List ein. So wie es auch der Kyro macht:

http://www.3dconcept.ch/reviews/3dprophet4500/tilesorter.gif

Bis hierhin ist die vorgehensweise mit dem Kyro identisch. Jetzt kommt aber das Rendering der einzelnen Tiles. Der Kyro geht bekanntlich mit dem Ray-Casting Verfahren Pixelweise vor, während der SIS hier Dreieck für Dreieck vorgeht, so wie ein IR das für die gesamte Bildfläche macht. Nur ist das hier eben auf ein Tile und die im Tile liegenden Dreiecke beschränkt:
Der Chip schaut sich jetzt das erste Tile an und redert die Dreiecke, die für dieses Tile in der Display-List eingetragen sind. Dies geschieht wie bei einem IR, d.h. nacheinander und mit Z-Buffer.
Allerdings natürlich nur so weit, wie das Dreieck in dem einzelnen Tile zu sehen ist. Wenn es darüber hinaus geht, wird der Rest ja eh' in einem anderen Tile gerendert.
Die Farbwerte werden ebenfalls auf dem On-Chip Cache gespeichert, der erst in den Framebuffer im Graka-RAM übertragen wird, wenn das komplette Tile fertiggerendert wurde, d.h. wie beim Kyro. Dadurch kann man eben alles - auch die Transparenzeffekte - in einem Pass rendern, während ein traditioneller IR immer mehrere Passes braucht (nämlich so viele, wie transparente Dreiecke vorhanden sind).

Nachdem Tile Nummer 1 fertiggerendert wurde und aus dem On-Chip-Cache in den Framebuffer kopiert wurde, kann man nun Tile Nummer 2 rendern usw.

Dieses Rendering ist eine Mischung aus TBR und IR, aber eben doch nicht ganz "immediate", weil eben erst die Display List erstellt wird. Das eigentliche Rendern geschieht dann Kachel für Kachel, aber wiederum doch so, wie es ein IR macht, d.h. Dreieck für Dreieck und mit Z-Buffer.
Das ist im Grunde nicht anders als die Vorgehensweise eines herkömmlichen IRs, bloß dass hier eben das Ganze nur auf einen kleinen Teil (bzw. Tile ;) ) des Bildes angewandt wird.
Und genau diesen Fakt kann man nutzen, in dem man mit kleinen Caches Z- und Framebufferzugriffe minimiert. Ein Cache für den gesamten Bildinhalt bei einem IR wäre viel zu groß und zu teuer. Da man aber immer nur einen Tile betrachtet, kann man eben dadurch sehr viel Speicherbandbreite sparen.

Fragen, Anregungen, Kommentare? ;)

edit: Ich behaupte nicht, dass der SIS das so macht (darüber habe ich keinerlei Information), auch wenn ich das hier geschrieben habe. Es ging lediglich darum, das Renderverfahren zu zeigen, wie man TBR auch mit einem IR kombinieren kann.
Ob das beim SIS dann wirklich so realisiert wird, ist eine ganz andere Frage...

edit2: Rechtschreibung, Grammatik, Ergänzungen etc.

[Xmas]

Originally posted by HOT
Erst mit dem Displacementmapping ist es möglich Einfluss auf die Geometrie vom Renderingprozess aus zu nehmen, wie das funktionieren soll, fragen wir am besten Matrox :D
Nein, Displacement Mapping kommt noch vor dem Vertex Shader und gehört rein zur Geometrie.

[HOT]

Originally posted by Xmas

Nein, Displacement Mapping kommt noch vor dem Vertex Shader und gehört rein zur Geometrie.

Auch gut :D

[ow]

Nichts auch gut:D

Das will ich doch gehofft haben, das Geometrie- und Pixelpipe weiterhin vollständig unabhängig bleiben.:)

[loewe]

Originally posted by GloomY
Ich glaube, du hast da was überlesen ;)
Eine TBR ohne Display List wäre - wie von dir richtig erwähnt - Schwachsinn.Also hier liegen mehrere Missverständnisse vor.

Ein Z-Buffer ist vorhanden (auf dem On-Chip-Cache) aber nicht im Graka-RAM.

Es handelt sich nicht um einen IR in dem Sinne, daß er sofort die einzelnen Dreiecke rendert.
Hier schaut er sich erst an, in welchen Tiles die einzelnen Dreicke liegen und sortiert diese dann in die Display List ein. So wie es auch der Kyro macht:
Bis hierhin ist die vorgehensweise mit dem Kyro identisch. Jetzt kommt aber das Rendering der einzelnen Tiles. Der Kyro geht bekanntlich mit dem Ray-Casting Verfahren Pixelweise vor, während der SIS hier Dreieck für Dreieck vorgeht, so wie ein IR das für die gesamte Bildfläche macht.


Ein beliebter Trugschluß!
Auch PowerVR geht die Displayliste Dreieck für Dreieck durch, also etwa nach folgendem Verfahren:


for Dreieck_1 bis Dreieck_n tue
for Tile_Zeile_1 bis Tile_Zeile_16 tue
begin
Bestimme zWert des DreieckPixel falls DreieckPixel in Zeile;
Wenn neuer_zWert kleiner alter_zWert dann zWert:=neuer_zWert;
end;
for Tile_Pixel_1 bis Tile_Pixel_512 tue
render Dreieck_Pixel mit kleinstem zWert;


D.h. es werden in einem Takt immer 32 Pixel eines Dreiecks gleichzeitig getestet, für ein Dreieck werden also 16 Takte gebraucht; gerendert wird nur das eine Pixel oder eben auch noch alle durchsichtigen, dann aber eben in einem Pass.
Der große Vorteil besteht auch darin, das so ein Dreick nur einmal je tile über den Bus übertragen werden muss, es wird ja immer nur genau einmal gebraucht.


Nur ist das hier eben auf ein Tile und die im Tile liegenden Dreiecke beschränkt:
Der Chip schaut sich jetzt das erste Tile an und redert die Dreiecke, die für dieses Tile in der Display-List eingetragen sind. Dies geschieht wie bei einem IR, d.h. nacheinander und mit Z-Buffer.
Allerdings natürlich nur so weit, wie das Dreieck in dem einzelnen Tile zu sehen ist. Wenn es darüber hinaus geht, wird der Rest ja eh' in einem anderen Tile gerendert.
Die Farbwerte werden ebenfalls auf dem On-Chip Cache gespeichert, der erst in den Framebuffer im Graka-RAM übertragen wird, wenn das komplette Tile fertiggerendert wurde, d.h. wie beim Kyro. Dadurch kann man eben alles - auch die Transparenzeffekte - in einem Pass rendern, während ein traditioneller IR immer mehrere Passes braucht (nämlich so viele, wie transparente Dreiecke vorhanden sind).

Nachdem Tile Nummer 1 fertiggerendert wurde und aus dem On-Chip-Cache in den Framebuffer kopiert wurde, kann man nun Tile Nummer 2 rendern usw.


Du stellst dir also einen tilebased deferred Renderer vor, das ist es nun mal was du beschreibst. Du verzichtest nur auf die füllratenschonenden Maßnahmen und beschränkst dich auf die Einsparrung von Bandbreite.


Dieses Rendering ist eine Mischung aus TBR und IR, aber eben doch nicht ganz "immediate", weil eben erst die Display List erstellt wird. Das eigentliche Rendern geschieht dann Kachel für Kachel, aber wiederum doch so, wie es ein IR macht, d.h. Dreieck für Dreieck und mit Z-Buffer.
Das ist im Grunde nicht anders als die Vorgehensweise eines herkömmlichen IRs, bloß dass hier eben das Ganze nur auf einen kleinen Teil (bzw. Tile ;) ) des Bildes angewandt wird.
Und genau diesen Fakt kann man nutzen, in dem man mit kleinen Caches Z- und Framebufferzugriffe minimiert. Ein Cache für den gesamten Bildinhalt bei einem IR wäre viel zu groß und zu teuer. Da man aber immer nur einen Tile betrachtet, kann man eben dadurch sehr viel Speicherbandbreite sparen.

Fragen, Anregungen, Kommentare? ;)

edit: Ich behaupte nicht, dass der SIS das so macht (darüber habe ich keinerlei Information), auch wenn ich das hier geschrieben habe. Es ging lediglich darum, das Renderverfahren zu zeigen, wie man TBR auch mit einem IR kombinieren kann.
Ob das beim SIS dann wirklich so realisiert wird, ist eine ganz andere Frage...


Ich frage mich gerade ob du damit nicht schon Probleme mit PowerVR bekommst, dein Verfahren entspricht doch weitgehend dem in den Patenten beschrieben Verfahren. Kennst du die Patente?
Hier auf Kristofs alter Seite: http://www.ping.be/powervr/index1024.htm kann man die alten Patente finden, die neueren sind soweit ich weiss bisher nicht frei.

Ich denke eigentlich nicht das SIS so ein Verfahren verwendet, ich frage mich ob bei dieser Art Aufwand und Nutzen in einem brauchbaren Verhältnis stehen.

:)

[GloomY]

Originally posted by loewe
Ein beliebter Trugschluß!
Auch PowerVR geht die Displayliste Dreieck für Dreieck durch, also etwa nach folgendem Verfahren:


for Dreieck_1 bis Dreieck_n tue
for Tile_Zeile_1 bis Tile_Zeile_16 tue
begin
Bestimme zWert des DreieckPixel falls DreieckPixel in Zeile;
Wenn neuer_zWert kleiner alter_zWert dann zWert:=neuer_zWert;
end;
for Tile_Pixel_1 bis Tile_Pixel_512 tue
render Dreieck_Pixel mit kleinstem zWert;
Hab' ich das jetzt richtig verstanden, dass beim rendern pixelweise vorgegangen wird und nur beim Testen Dreieck für Dreieck?Originally posted by loewe
D.h. es werden in einem Takt immer 32 Pixel eines Dreiecks gleichzeitig getestet, für ein Dreieck werden also 16 Takte gebraucht; gerendert wird nur das eine Pixel oder eben auch noch alle durchsichtigen, dann aber eben in einem Pass.
Der große Vorteil besteht auch darin, das so ein Dreick nur einmal je tile über den Bus übertragen werden muss, es wird ja immer nur genau einmal gebraucht.Von welchem Bus sprichst du jetzt? Speicherbus oder AGP?
Originally posted by loewe
Du stellst dir also einen tilebased deferred Renderer vor, das ist es nun mal was du beschreibst.Hmm, immerhin hab' ich jetzt dann mal einen Namen dafür. ;) Aber "Tilebase deferred Renderer" ? Hmm, was ist dann der Kyro? Der ist ja sowohl "Tilebased" als auch "deferred"... ? ???
Originally posted by loewe
Du verzichtest nur auf die füllratenschonenden Maßnahmen und beschränkst dich auf die Einsparrung von Bandbreite.Imho ist das der notwendigste Schritt. Seit dem TNT 2 sind alle IRs speicherbandbreitenlimitiert. GF3 und 4 auf Grund einiger Optimierungen weniger stark als z.B. GF2 oder GF1 SDR. Bei ATI ist es ähnlich (auch wenn ich da nicht so ganz den Überblick habe).
Füllrate kann man theoretisch mit beliebig vielen Pixelpipelines in ausreichendem Maße zur Verfügung stellen.
Speicherbandbreite ist vor allem durch die Qualtität (bzw. dem Takt) der Speicherchips abhängig. Und das ist wiederum von der Strukturbreite der Chips bei der Produktion abhängig, die aber nicht in beliebiger Länge und Geschwindigkeit verkleinert werden kann.
Sicher könnte man mit einer Erhöhung der Bandbreite auf 256 Bit DDR oder einem zweiten Speicherinterface noch ein bisschen was rauskitzeln, aber diese Lösungen sind alle samt nicht gerade billig...
Originally posted by loewe
Ich frage mich gerade ob du damit nicht schon Probleme mit PowerVR bekommst, dein Verfahren entspricht doch weitgehend dem in den Patenten beschrieben Verfahren. Kennst du die Patente?Nein, damit habe ich mich noch gar nicht beschäftigt.
Originally posted by loewe
Hier auf Kristofs alter Seite: http://www.ping.be/powervr/index1024.htm kann man die alten Patente finden, die neueren sind soweit ich weiss bisher nicht frei.Danke für die Info. Ich werde bei Gelegenheit mal reinschauen =)
Originally posted by loewe
Ich denke eigentlich nicht das SIS so ein Verfahren verwendet, ich frage mich ob bei dieser Art Aufwand und Nutzen in einem brauchbaren Verhältnis stehen.Imho ist das ja ein fast normaler IR, der eben nacheinander nur die einzelnen Tiles und die darin enthaltenen Dreiecke rendert. So wie man es eben mit dem gesamten Bildschirm und alle Dreiecken bei einem echten IR macht. Von daher sehe ich nicht all zu viele Schwierigkeiten, ein solches Verfahren zu realisieren.

P.S.: Wie war das jetzt eigentlich mit der Aussage von www.tilebase.de, dass dort einzelne Pixel aus der Display List gelöscht werden? Ist doch unlogisch, da sich keine Pixel, sondern die Dreiecksnummern in der Display List befinden.
Aber nach deiner Beschreibung sollte an der Liste selbst ja gar nichts geäandert werden... ???

P.S.2: Immerhin hätten wir jetzt geklärt, dass es einen Deferred Renderer mit Z-buffer gibt, was ja schliesslich der Ausgangspunkt der Diskussion war...

[Modulor]

Originally posted by GloomY

...
P.S.: Wie war das jetzt eigentlich mit der Aussage von www.tilebase.de, dass dort einzelne Pixel aus der Display List gelöscht werden? Ist doch unlogisch, da sich keine Pixel, sondern die Dreiecksnummern in der Display List befinden.
Aber nach deiner Beschreibung sollte an der Liste selbst ja gar nichts geäandert werden... ???
...

Da hat der Verfasser der Seiten den Sachverhalt wahrlich nicht korrekt dargestellt - ist aber auch schon länger her (August 2001) als ich eigentlich nur mir persönlich die gänzlich andere Funktionsweise des KYRO näherbringen wollte (merkt man auch am Schreibstil: KYRO for Dummies ;)). Zum einen wußte ich es nicht besser und zum anderen konnte ich ja nicht ahnen, daß Monate später diese Zeilen auch noch auf 3DC auftauchen werden :D ...

Wird bei Gelegenheit korrigiert !

[ow]

Gloomy

Alle deine theoretische Rechnerei bringt nichts.

Ein solcher Chip hätte kein Vorteile gegenüber der Kyro-Architektur.

Die Aussage, dass Chips ab TNT2 durch die Bandbreite limitiert sind, ist so pauschal falsch.

Theoretisch kannst du alles, aber was glaubst du, warum die Anzahl der Pixelpipes in den Chips so gering ist?

Ein TBR macht nur mit HSR Sinn, um Füllrate zu sparen.

[loewe]

Originally posted by GloomY
Hab' ich das jetzt richtig verstanden, dass beim rendern pixelweise vorgegangen wird und nur beim Testen Dreieck für Dreieck?

Ja beim Testen wird seit Serie3 Dreieck für Dreieck getestet, fürher war das anders.
Wie sollte sonst beim Rendern vorgegangen werden, die Dreicke spielen hier ja eigentlich keine Rolle mehr. Selbst für den Fall das mehrere durchsichtige Pixel auf der Scanline auftreten wird eben für das Pixel eine Schleife aufgerufen.

Von welchem Bus sprichst du jetzt? Speicherbus oder AGP?
Hmm, immerhin hab' ich jetzt dann mal einen Namen dafür. ;) Aber "Tilebase deferred Renderer" ? Hmm, was ist dann der Kyro? Der ist ja sowohl "Tilebased" als auch "deferred"... ? ???

Grundsätzlich vom Speicherbus, nach Möglichkeit sollte man ja auf die Auslagerung im Arbeitsspeicher und damit dann doch AGP Bus verzichten.
KYRO ist ein tilebased deferred Renderer. :)

P.S.: Wie war das jetzt eigentlich mit der Aussage von www.tilebase.de, dass dort einzelne Pixel aus der Display List gelöscht werden? Ist doch unlogisch, da sich keine Pixel, sondern die Dreiecksnummern in der Display List befinden.
Aber nach deiner Beschreibung sollte an der Liste selbst ja gar nichts geäandert werden... ???

P.S.2: Immerhin hätten wir jetzt geklärt, dass es einen Deferred Renderer mit Z-buffer gibt, was ja schliesslich der Ausgangspunkt der Diskussion war...

Naja, die Frage ist ja auch gar nicht so dumm. Die ersten PowerVR Chips hatten keinen Z-Buffer. Da ist damals wirklich versucht worden die Dreiecke zu sortieren, hat sioch aber nicht bewehrt.
:)

[GloomY]

Originally posted by Modulor
Da hat der Verfasser der Seiten den Sachverhalt wahrlich nicht korrekt dargestellt - ist aber auch schon länger her (August 2001) als ich eigentlich nur mir persönlich die gänzlich andere Funktionsweise des KYRO näherbringen wollte (merkt man auch am Schreibstil: KYRO for Dummies ;)). Zum einen wußte ich es nicht besser und zum anderen konnte ich ja nicht ahnen, daß Monate später diese Zeilen auch noch auf 3DC auftauchen werden :D ...

Wird bei Gelegenheit korrigiert ! Ach, die Seite ist von dir? Hab' ich gar net gewusst...

[GloomY]

Originally posted by ow
GloomY

Alle deine theoretische Rechnerei bringt nichts.

Ein solcher Chip hätte kein Vorteile gegenüber der Kyro-Architektur.
Zumindest wäre ein solcher Chip einfacher zu realisieren, als das HSR beim Kyro mit den Sehstrahlen und den Beschreibung eines Dreiecks als 4 unendliche Ebenen usw. ...
Das fällt eben bei einer solchen Architektur weg. Und da es wie schon erwähnt praktisch ein IR ist, der sich auf den Inhalt eines Tiles beschränkt, dürfte der Umstieg von einem IR auf das von mir aufgezeigte Modell nicht all zu schwere sein.
Originally posted by ow
Die Aussage, dass Chips ab TNT2 durch die Bandbreite limitiert sind, ist so pauschal falsch.Und warum fällt die Performance dann beim Umstieg von 16 auf 32 Bit Framebuffer vor allem in hohen Auflösungen um (teilweise) mehr als 40% ?
Originally posted by ow
Theoretisch kannst du alles, aber was glaubst du, warum die Anzahl der Pixelpipes in den Chips so gering ist?Ich weiss es nicht. Sag' du es mir doch.
Originally posted by ow
Ein TBR macht nur mit HSR Sinn, um Füllrate zu sparen.Wie bereits weiter oben aufgezeigt, ist das eben nicht der Fall. Speicherbandbreite ist ein teueres Gut, dass man mit einem TBR ebenso einsparen kann wie mit HSR Füllrate...

[HOT]

Meiner Meinung nach ist der Chip nur ein TBR, weil SIS sich auf einen deferred Renderer vorbereitet. Warum soll man noch einen SGI Chip entwickeln, wenn man so die Entwicklung des Nachfolgemodells erheblich verkürzen kann? Ich glaube, dass hier wirtschaftliche Gründe die Hauptrolle spielen.

[MadManniMan]

hab mir grad ncohmal den glaze3d rückblick auf tommti reingezogen und siehe da, dieser war auch ein tile-based IR

allerdings sah man die tiles für ne bessere multichiplösung vor...

[HOT]

Ausserdem wäre es sonst mit dem eDRAM kompliziert geworden.

[MadManniMan]

meinst? hab ich da was überlesen?

[StefanV]

Ich würde den letzten 3dfx Treiber empfehlen...


Von der V5 natürlich ;)

[Xmas]

Originally posted by Stefan Payne
Ich würde den letzten 3dfx Treiber empfehlen...


Von der V5 natürlich ;)
So früh am morgen schon besoffen? ;)

[Quasar]

Originally posted by Stefan Payne
Ich würde den letzten 3dfx Treiber empfehlen...


Von der V5 natürlich ;)

Ich auch, der hilft am besten gegen den Kater!

[StefanV]

Originally posted by Xmas
So früh am morgen schon besoffen? ;)

Nee, falschen Thread erwischt :/

SOWAS kommt vor, wenn man mehrere Fenster gleichzeitig geöffnet hat und 'aus versehen' das falsche Fenster erwischt und sich vorher nicht den Titel des Threads durchliest...

ARGH...

[MadManniMan]

jop, oder man feststellt, daß neben dem icq auch das forum per alt+s postet... peinlich, peinlich!

[StefanV]

Originally posted by MadManniMan
jop, oder man feststellt, daß neben dem icq auch das forum per alt+s postet... peinlich, peinlich!

DAS weiß ICH schon seeeeeeehhhhhhhhhrrrr lange =)

bei Foren, die das nicht können, hilft meist TAB+ENTER weiter *eg*...

Aber hier, sowie in YaBB GOLD SP1/SE benutze ich IMMER ALT+S...


ALT+S

[[fu]121Ah]

die v5 ist füllratenlimitiert.... nicht bandbreiten...

[Quasar]

auch besoffen, Fu?

[[fu]121Ah]

nope quasar, wäre es gerne :)

leider sind meine ferien vorbei und der alk ist weg... caipirinha ist verdammt gut...

soweit ich das weis oder getestet habe, ist sie wirklich füllratenlimitiert... oder auf jeden fall eher als ne geforce oder radeon...

[ow]

Hi Gloomy

Ich hoffe es stoert dich nicht, wenn ich den alten Thread nochmal auskrame...


Originally posted by GloomY
=)

Um mal wieder zum Theam zurückzukommen:
SIS mit seinem Tile- und SGI-Renderer

Hätte folgende Vorteile:

.....

Zusätzlich dazu kann man alles andere in einem Pass rendern. Und das gilt auch für transparente Dreicke, für die ein IR IMMER mehrere Passes braucht (da hilft auch kein Loopback einer GF3 oder GF4).




Du scheinst den Begriff des "Passes" voellig falsch zu gebrauchen.
Auch ein IR rendert Transparenz IMMER single pass. Ebenso wie der Kyro und deine "TBR_ohne_HSR" Architektur.

[Xmas]

Hm, ich bin mir jetzt auch nicht sicher was Gloomy meint.
Aber ein pixelbasierter deferred Renderer muss jeden Pixel nur genau einmal schreiben und kann jede Transparenzschicht als zusätzliche Textur verarbeiten. Ein dreiecksbasierter Renderer dagegen muss, auch wenn vorher - auf welche Art auch immer - der Overdraw minimiert wurde, für jedes transparente Polygon einen Read-Modify-Write-Zyklus durchlaufen.

[ow]

Gloomy sprach doch von einem Tiler, der innerhalb der einzelnen Tiles wie ein IR arbeitet, aber Tile-/Z-Buffer onchip liegen und nur fertig berechnete Tiles in den Framebuffer geschrieben werden.