Wie intelligent sind aktuelle Grafikchips? [Archiv]

)Charly(

2008-06-03, 23:13:08

Hallo zusammen,
Ich habe da mal eine frage?
Wie intelligent sind aktuelle Grafikchips was das Rendern angeht?
Gehen die Chiphersteller immer noch mit der Brechstange vor, wird also immer noch alles berechnet was auf dem Bildschirm sichtbar sein "könnte".

Ich finde leider keine Artikel zu solchen Themen. Ich versuche mal ein beispiel zu geben:

Wenn ich vor einer Tür stehe was seht Ihr dann? Zuerst mich und hinter bzw. um mich herum, den rest der Türe. Was wird berechnet? Ich und die ganze Türe anstatt mich und den rest der Türe.... was nach meinem Denken viel zu viel Rechenleistung kostet und auch viel mehr Speicherplatz benötigt.

Gast

2008-06-03, 23:51:06

das ist wohl eher engine, denn graka-abhängig.

Gast

2008-06-04, 00:07:41

grafikchips sind nicht intelligent.

)Charly(

2008-06-04, 00:24:28

Das ist wohl kaum die engine höchstens ein Zusammanspiel wäre denkbar.

Danke an anderer Gast...... Pcs sind ja zum Glück immer nur so intelligent wie das Individuum welches sich zwischen Stuhl und Tastatur befindet......

Hier noch etwas uraltes aus dem Jahr ?? 99 oder so:
http://www.3dconcept.ch/reviews/3dprophet4500/5.htm

deekey777

2008-06-04, 00:26:27

das ist wohl eher engine, denn graka-abhängig.

"Oblivion" als Ausnahme bestätigt die Regel.

Sonst lohnt sich vielleicht ein Blick in diesen Artikel: Warum liegt die Radeon X800 Serie unter Doom 3 zurück? (http://alt.3dcenter.org/artikel/2004/07-30.php) (Zusammenspiel Grafikkarte <-> Doom-3-Engine)

HSR: Hidden Surface Removal (http://alt.3dcenter.org/artikel/2002/11-14_a.php)

Hallo zusammen,
Ich habe da mal eine frage?
Wie intelligent sind aktuelle Grafikchips was das Rendern angeht?
Gehen die Chiphersteller immer noch mit der Brechstange vor, wird also immer noch alles berechnet was auf dem Bildschirm sichtbar sein "könnte".

Ich finde leider keine Artikel zu solchen Themen. Ich versuche mal ein beispiel zu geben:

Wenn ich vor einer Tür stehe was seht Ihr dann? Zuerst mich und hinter bzw. um mich herum, den rest der Türe. Was wird berechnet? Ich und die ganze Türe anstatt mich und den rest der Türe.... was nach meinem Denken viel zu viel Rechenleistung kostet und auch viel mehr Speicherplatz benötigt.
Da denke ich an den Artikel (http://www.ixbt.com/video2/tech_trl.shtml) zu "Tomb Raider: Legend" von iXBT, wo Lara vor einer Wand steht, dabei um 3 Mio Dreiecke berechnet werden und der "Drahtgitter-Blick" verrät, dass alles, was hinter der Wand ist (was natürlich unsichbar ist), berechnet wird. Auch in Crysis kann man von einer Felswand stehen und in der Anzeige 2 Mio Polys bewundern.
Und da ich mich darüber so mächtig aufgeregt habe, fragte ich Demirug, warum das so ist, seine Antwort:
Die meisten Engines mit Outdoor support sind beim culling schlecht. Zum Teil ist es leider noch teurer die Objekte von der CPU cullen zu lassen als den Overhead zu bezahlen

Das betrifft aber die Geometrie. Durch die Spässe wie Hier-Z werden "unsichtbare" Pixel, so weit es geht, verworfen. Die, die nicht verworfen werden können (zB nur ein sichtbarer Pixel eines Quads) werden als "unsichtbar" markiert, aber deren Farbwerte werden berechnet.

Gast

2008-06-04, 00:30:47

"Oblivion" als Ausnahme bestätigt die Regel.

Sonst lohnt sich vielleicht ein Blick in diesen Artikel: Warum liegt die Radeon X800 Serie unter Doom 3 zurück? (http://alt.3dcenter.org/artikel/2004/07-30.php) (Zusammenspiel Grafikkarte <-> Doom-3-Engine)

HSR: Hidden Surface Removal (http://alt.3dcenter.org/artikel/2002/11-14_a.php)
+ Occlusion Queries
+ Predicated Rendering

Coda

2008-06-04, 01:16:46

Grafikkarten sind schon seit Generationen sehr effizient dabei Dreiecke komplett wegzuwerfen nach dem Tri-Setup falls sie komplett verdeckt sind.

Das funktioniert solange man von vorne nach hinten grob sortiert in den Engine recht gut. Problem dabei ist, dass die Vertexarbeit trotzdem anfällt.

Joeb (Gast)

2008-06-05, 06:44:43

Gast

2008-06-05, 16:27:11

Also das GraKarten Dreiecke schon beim Setup (im Vertex/Geometry-Shader
Einheit) wegschmeissen, wag ich mal zu bezweifeln. Man muss nur mal
überdenken, was es heisst Dreiecke mit 100 oder mehr Pixel schnell auf
Sichtbarkeit zu testen.

natürlich nicht, wäre auf der GPU auch relativ sinnlos, gänzlich unsichtbare dreiecke sollten nach möglichkeit erst garnicht auf die gpu kommen.

Coda

2008-06-05, 19:21:41

Also das GraKarten Dreiecke schon beim Setup (im Vertex/Geometry-Shader Einheit) wegschmeissen, wag ich mal zu bezweifeln. Man muss nur mal überdenken, was es heisst Dreiecke mit 100 oder mehr Pixel schnell auf Sichtbarkeit zu testen.
Erstmal sorry, dass ich den falschen Knopf erwischt habe. Ich bin das noch nicht gewöhnt.

Zum Thema: Es ist wirklich so. Radeons verwerfen durch den hierarchischen Z-Buffer nach dem Trisetup komplette Dreiecke. Schon seit R100. In der obersten Hierarchie wird der z.B. höchste Z-Wert des Frames gespeichert, jedes Dreieck das alle Eckpunkte dahinter hat kann sofort komplett verworfen werden.

NVIDIA verwendet ein ähnliches Verfahren das aber soweit ich weiß zumindest vor einiger Zeit noch nicht hierarchisch gearbeitet hat sondern mit Kacheln.

natürlich nicht, wäre auf der GPU auch relativ sinnlos, gänzlich unsichtbare dreiecke sollten nach möglichkeit erst garnicht auf die gpu kommen.
Das hat aber nichts mit dem Thema zu tun. Und doch. Sie tun es ;)

Gast

2008-06-05, 20:24:42

Fazinierend, zur Zeiten der Kyro2 haben sich 3Dfx und NV mit HSR-Optionen im Treiber überschlagen. Richtiges Kyro-HSR hatte ein großes Manko, was die Spezis hier sicher erklären können... so konnte man keine Cad-Programme nutzen, denn durch das HSR wurde irgendwie die Berechnung zur Markierung fehlerhaft durchgeführt. So klickte man ein Objekt im 3D-Fenster im Vordergrund an und es wurde stattdessen ein dahinterliegendes Objekt markiert.

Gast

2008-06-05, 21:46:24

...
Zum Thema: Es ist wirklich so. Radeons verwerfen durch den hierarchischen Z-Buffer nach dem Trisetup komplette Dreiecke. Schon seit R100. In der obersten Hierarchie wird der z.B. höchste Z-Wert des Frames gespeichert, jedes Dreieck das alle Eckpunkte dahinter hat kann sofort komplett verworfen werden.

NVIDIA verwendet ein ähnliches Verfahren das aber soweit ich weiß zumindest vor einiger Zeit noch nicht hierarchisch gearbeitet hat sondern mit Kacheln.
...

@Coda,

wird hier. Z-Buffer automatisch erzeugt oder muss mann ein entsprechendes
Flag (z.B. in D3DDevice..) setzen.

Vor vieleicht einem Jahr habe ich mal eine Bench gesehen, die Occlusion
Querier untersuchte. Ob jetzt NVidia oder ATI besser abschnitt, weiss ich
nicht mehr. Aber mit O.Q. wars auf jeden fall deutlich schneller. Ein Beispiel
dazu findet man z.B. im Buch GPU2, wo eine Stadt-Szene schneller gezeichnet
wurde. Also von daher frage ich mich, was hierachical Z-Buffering bringt.

Gruss

Jörg

IceKillFX57

2008-06-07, 00:14:49

Ich hatte mal ein heft wo drin stand das die GeForce 6800 nur das Gerendert hat was sieht.
Sprich das was z.B hinter deiner waffe ist und man nicht sieht wird nicht berechnet.
Getestet wurde das mit Doom 3.

Gast

2008-06-07, 12:01:42

Ich hatte mal ein heft wo drin stand das die GeForce 6800 nur das Gerendert hat was sieht.

Getestet wurde das mit Doom 3.

mit einer engine mit vorgezogenem Z-pass (wie doom3) stimmt das auch, wie bei jeder anderen karte auch. ohne z-pass kann die 6800 auch nur dreiecke verwerfen, wenn diese F2B gerendert werden.

IceKillFX57

2008-06-07, 12:46:16

mit einer engine mit vorgezogenem Z-pass (wie doom3) stimmt das auch, wie bei jeder anderen karte auch. ohne z-pass kann die 6800 auch nur dreiecke verwerfen, wenn diese F2B gerendert werden.

ich wünschte ich würde verstehen wovon du da redest^^

Ich hab selber davon k.A hab nur gesagt was ich ihm Heft gesehen habe^^
Da war das noch neu.

Gast

2008-06-07, 14:39:49

ich wünschte ich würde verstehen wovon du da redest^^

Doom3 und auch einige anderen spiele machen zuerst einen Z-only-pass. in diesem wird lediglich der Z-buffer erzeugt und keinerlei pixel berechnet.
erst im 2. pass werden nun die eingentlichen pixel berechnet, da man allerdings den finalen z-buffer schon kennt muss man das auch nur mit sichtbaren objekten machen.

vorteil an der sache ist natürlich, dass man sich das rendern unsichtbarer objekte komplett erspart. nachteilig ist vor allem, dass man beispielsweise das gesamte vertexshading doppelt machen muss.

Gast

2008-06-07, 19:29:00

Doom3 und auch einige anderen spiele machen zuerst einen Z-only-pass. in diesem wird lediglich der Z-buffer erzeugt und keinerlei pixel berechnet.
erst im 2. pass werden nun die eingentlichen pixel berechnet, da man allerdings den finalen z-buffer schon kennt muss man das auch nur mit sichtbaren objekten machen.

vorteil an der sache ist natürlich, dass man sich das rendern unsichtbarer objekte komplett erspart. nachteilig ist vor allem, dass man beispielsweise das gesamte vertexshading doppelt machen muss.

Dieses Prinzip findet sich vollständig wieder in DeferedRendering: Hier werden
auch nur einige Basis-Daten in das RenderTarget geschrieben (TexCoords,
TexIndex etc). Im zweiten Schritt wird dann das fertige Bild erzeugt.

Gruss

Jörg

Gast

2008-06-07, 20:29:57

Dieses Prinzip findet sich vollständig wieder in DeferedRendering:

Deferred Rendering geht noch deutlich weiter als "nur" den Z-pass vorzuziehen.

RavenTS

2008-06-09, 01:33:22

Wird mal wieder Zeit für paar Technikartikel ;)

del_4901

2008-06-09, 01:58:22

Wird mal wieder Zeit für paar Technikartikel ;)
Wiso, damit noch mehr Leute glauben zu wissen, wovon sie reden? Und sich das gefährliche Halbwissen noch weiter verbreitet? Sorry, aber bei dem was ich so gesehen habe, was dabei rumkommt, bin ich inzwischen gegen solche Artikel. Wer wissen will wie das ganze funktioniert, der soll sich nen Buch kaufen, wo das genau auseinandergenommen wird.

=Floi=

2008-06-09, 02:09:56

welcher bücher hast denn du gelesen?

del_4901

2008-06-09, 02:12:15

welcher bücher hast denn du gelesen?
Soll ich jetzt ne Aufzählung machen oder was? lol
Es sind schon mehrere 1000e Euro für Bücher draufgegangen, soviel dazu.

Gast

2008-06-09, 06:17:22

Naja, ob in Büchern wirklich soviel mehr zu finden ist als in aktuellen Foren
und Artikeln, glaube ich kaum. Z.B. die NVidia-Serie GPU-Gems I-III und
die ShaderX I-? hinken ja oft mehr als ein Jahr hinterher. Z.B. wurden
Relief-Shader schon mehr als 3 Jahre vor den beiden Buchserien eingeführt.
RigidBody-Simulationen gabs sogar schon viele Jahre vorher. Positiv an
den Buchserien ist aber die gute Aufmachung (wenn auch die Artikel
relativ oberflächlich gehalten sind.

Am Besten, man schaut regelmässig bei den Developer-Seiten von ATI
und NVidia vorbei. Gute Quellen sind auch Internet-Seiten diverser
Universitäten. Dort am Besten die PDFs runterladen, sich einen Rahmen
(C++, z.B. für D3D) schreiben und dann ein wenig rumspielen.

Gruss

Jörg

tikiman

2008-06-13, 02:28:04

Warum hat sich das TBR-Konzept des Kyro eigentlich nicht durchgesetzt? Hat die Technik einen gravierenden Haken?

dust

2008-06-13, 07:01:50

http://www.openscenegraph.org

sehr viele infos

del_4901

2008-06-13, 07:09:55

http://www.openscenegraph.org

sehr viele infos
Ein SceneGraph ist nur eines von vielen Culling Verfahren. Und ganz nebenbei, find ich den OSG nicht so prall, denn die eierlegende Wollmilchsau funktioniert doch nicht so ganz, wie sie sollte. Zumal ein eigener SG relativ schnell geschrieben ist, den man dann auch vernünftig auskoppeln kann, und der auch auf die eigenen Bedürfnisse angepasst werden kann.

dust

2008-06-13, 07:14:10

Ein SceneGraph ist nur eines von vielen Culling Verfahren. Und ganz nebenbei, find ich den OSG nicht so prall, denn die eierlegende Wollmilchsau funktioniert doch nicht so ganz, wie sie sollte.

was soll an osg nicht funktionieren?

del_4901

2008-06-13, 07:17:32

was soll an osg nicht funktionieren?
Der ist einfach ungeeignet wenn es um Geschichten wie Physik Sound etc (alles was nicht mit GFX zu tun hat) gehen soll, du kannst dir zwar nen eigenen Node Visitor schreiben, aber das bringt dir gar nichts, außer noch mehr Probleme. Zumal der echt fest an GL gekoppelt wurde, und das ist schonmal ein scheiss Design.

dust

2008-06-13, 08:15:14

Der ist einfach ungeeignet wenn es um Geschichten wie Physik Sound etc (alles was nicht mit GFX zu tun hat) gehen soll, du kannst dir zwar nen eigenen Node Visitor schreiben, aber das bringt dir gar nichts, außer noch mehr Probleme. Zumal der echt fest an GL gekoppelt wurde, und das ist schonmal ein scheiss Design.der sinn von einem scenegraph ist grafik und nicht physik, sound usw.

wenn du physik willst kannst du ode, bullet und andere verwenden, für sound openal, für eingabegeräte sdl. schau dir die beispiele auf der osg seite an.
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials
* ODE Demo: a little Open Dynamics Engine (ODE) example that uses OSG for visualization. LMBs_ODE_Demo.zip. Patch by Hans Ulrich Niedermann to use osgViewer instead of osgProducer: LMBs_ODE_Demo-osgViewer.patch (by Leandro Motta Barros)

* Bullet demo: a little demo application showing integration of OSG and (Bullet) physics engine. bullet-test.tar.gz. Archive contains a CDT project (Eclipse C++ IDE), the code is tested and working with Bullet 2.68 and OSG 2.4 (by Jan Ciger).
für plattformunabhängigkeit selbstverständlich opengl, derzeit version 2 in zukunft auch die 3er. realtime raytracing gibt es auch schon ein beispiel und ein paar leute die daran arbeiten.
http://www.openscenegraph.org/projects/osg/wiki/RayTraced

http://www.delta3d.org/
Features

Delta3D is an Open Source engine which can be used for games, simulations, or other graphical applications. Its modular design integrates well-known Open Source projects such as Open Scene Graph (OSG), Open Dynamics Engine (ODE), Character Animation Library (CAL3D), and OpenAL as well as projects such as Trolltech’s Qt, Crazy Eddie’s GUI (CEGUI), Xerces-C, Producer, InterSense Tracker Drivers, HawkNL, and the Game Networking Engine (GNE). Rather than bury the underlying modules, Delta3D integrates them together in an easy-to-use API which allows direct access to important underlying behavior when needed. Delta3D renders using OpenSceneGraph and OpenGL.

The primary goal of Delta3D is to provide a single, flexible API with the basic elements needed by all visualization applications. In addition to the underlying components, Delta3D provides a variety of tools such as the Simulation, Training, and Game Editor (STAGE), the BSP Compiler, the particle editor, a stand-alone model viewer, and a HLA Stealth Viewer. Further, Delta3D has an extensive architectural suite that is integrated throughout the engine. This suite includes frameworks such as the Application Base Classes (ABC) for getting started; the Dynamic Actor Layer (DAL) for Actor Proxies and Properties; signal/slot support for direct method linking; the Game Manager (GM) for actor management; pluggable terrain tools for reading, rendering, and decorating terrain; and high-level messaging for actor communication. da hast du schon alles zusammen.

del_4901

2008-06-13, 09:05:20

der sinn von einem scenegraph ist grafik und nicht physik, sound usw.

Du musst es ja wissen

wenn du physik willst kannst du ode, bullet und andere verwenden, für sound openal, für eingabegeräte sdl. schau dir die beispiele auf der osg seite an.
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials

Und was ist wenn ich z.B kein OpenAL verwenden moechte sondern Fmod, oder APEX fur die Physik?

für plattformunabhängigkeit selbstverständlich opengl, derzeit version 2 in zukunft auch die 3er.
So selbstverstaendlich ist das nicht!

da hast du schon alles zusammen.
Da sind Sachen dabei, die ich nicht brauch, wiso kann ich die nicht "aushaengen"?

dust

2008-06-13, 10:03:39

Und was ist wenn ich z.B kein OpenAL verwenden moechte sondern Fmod, oder APEX fur die Physik? dann verwendest eben fmod und apex. du bist ja nicht gezwungen eine bestimmte api zu verwenden sondern kannst dir aussuchen was du nehmen willst.

So selbstverstaendlich ist das nicht!wer sich auf ms und direktx festlegt ist selbst schuld, der markt abseits von ms ist gross.

Da sind Sachen dabei, die ich nicht brauch, wiso kann ich die nicht "aushaengen"?kannst du ja, delta3d ist ein beispiel wie man die einzelnen unterschiedlichen api wie osg, ode, openal usw. zusammenhängen kann aber nicht muss.

loewe

2008-06-13, 19:22:53

Warum hat sich das TBR-Konzept des Kyro eigentlich nicht durchgesetzt?
Wieso, es hat sich doch durchgesetzt! ;)
Im mobilen Bereich ist wohl gegenwärtig niemand in der Lage, mit MBX bzw. SGX vergleichbares zu liefern.
BTW, das was du meinst ist wohl eher TBDR, tilebased ist heute irgendwie jeder.
Hat die Technik einen gravierenden Haken?
Nein! :)

Gast

2008-06-13, 19:50:21

Nein! :)
Für manche Leute ist Raytracing der heilige Gral und für dich ists TBDR. X-D

haifisch1896

2008-06-13, 20:01:08

Gast

2008-06-13, 20:02:15

Nein! :)

naja schon, die gesamte geometrie muss vor dem rendering sortiert werden, das könnte durchaus zum flaschenhals werden.

loewe

2008-06-13, 21:01:01

naja schon, die gesamte geometrie muss vor dem rendering sortiert werden, das könnte durchaus zum flaschenhals werden.
Falsch, da wird nichts sortiert.

loewe

2008-06-13, 21:08:21

TBDR hat einen gravierenden Haken. Man muss die Architektur komplett umstellen, kann nicht mehr die selben Pipelines aufbohren und nutzen (soweit ich weiß!!!) und muss allein in den Entwicklungsaufwand eine ganze Menge Kohle stecken.
Es wäre quasi im Gegensatz zum IMR eine (teure!) Revolution, und die Weiterentwicklung der IMR nur eine (billigere!) Evolution.
Ich sehe im Moment nur einen "gravierenden Haken", alle wesentlichen Teile sind durch PowerVR patentiert. ;)
Für NV oder ATI wäre es sicher ein erheblicher Aufwand etwas ähnliches zu entwickeln ohne ImgTec auf die Füße zu treten und wie du schon sagst, man muss sich entscheiden TBDR oder IMR.

Gast

2008-06-13, 21:50:45

Ich sehe im Moment nur einen "gravierenden Haken", alle wesentlichen Teile sind durch PowerVR patentiert. ;)
Für NV oder ATI wäre es sicher ein erheblicher Aufwand etwas ähnliches zu entwickeln ohne ImgTec auf die Füße zu treten und wie du schon sagst, man muss sich entscheiden TBDR oder IMR.
Intel steigt jetzt wieder neu in den Markt ein und hätte sich nicht an ein paar Patente von PowerVR stören müssen. Die Firma hätte man aus der Portokasse gekauft, wenn es sinnvoll gewesen wäre.
Obwohl sie kein Designgrundlage hatten, die sie dazu genötigt hätte Altlasten mit sich herumrumzuschleppen, bauen sie weder TBDR noch Raytracingchip.

Coda

2008-06-13, 22:27:15

Falsch, da wird nichts sortiert.
Die ganze Geometrie muss vortransformiert werden und dann wird Raycasting auf die Tiles gemacht. So ganz billig ist das nicht.

loewe

2008-06-14, 20:22:00

Intel steigt jetzt wieder neu in den Markt ein und hätte sich nicht an ein paar Patente von PowerVR stören müssen. Die Firma hätte man aus der Portokasse gekauft, wenn es sinnvoll gewesen wäre.
Obwohl sie kein Designgrundlage hatten, die sie dazu genötigt hätte Altlasten mit sich herumrumzuschleppen, bauen sie weder TBDR noch Raytracingchip.
Ich weiß nicht was intel tut und entwickelt, aber sie verwenden auf jeden Fall auch PowerVR Technologie, bekannt bisher im Poulsbo Chipsatz, das wird aber wohl nicht die einzige Verwendung bleiben.

haifisch1896

2008-06-14, 20:33:40

Fang aber bitte nicht an, von einer Series6 (?) als Desktop-GK zu träumen, auch wenn es ein Wunsch meinerseits wäre. Dafür wissen wir zu wenig und dran glauben tu ich nicht mehr.

loewe

2008-06-14, 20:35:33

Die ganze Geometrie muss vortransformiert werden und dann wird Raycasting auf die Tiles gemacht. So ganz billig ist das nicht.
Hat auch keiner gesagt.
Aber was bedeutet hier "vortransformiert"? Die Geometrie wird genauso wie in jedem anderen Grafikchip bearbeitet, sprich durch die Vertexshader gejagt und anschließend den Tiles zugeordnet. Tiling ist Culling, sprich was nicht in die Tiles passt oder zu klein ist, wird sofort verworfen.
AFAIK kommen in der Displayliste(n) weniger als die Hälfte der Dreiecke an, was schon einen wesentlicher Beitrag des TA darstellt.

loewe

2008-06-14, 20:40:41

Fang aber bitte nicht an, von einer Series6 (?) als Desktop-GK zu träumen, auch wenn es ein Wunsch meinerseits wäre. Dafür wissen wir zu wenig und dran glauben tu ich nicht mehr.
Wovon ich träume, darüber werde ich hier nichts schreiben! :D

Aber, ich hab mal irgendwo gehört das SGX etwa 50% mehr Leistung bringt, als ein Core mit ähnlicher Transistorzahl der anderen Mitbewerber, ist aber schon eine Zeit her! ;)

del_4901

2008-06-14, 21:05:32

Hat auch keiner gesagt.
Aber was bedeutet hier "vortransformiert"? Die Geometrie wird genauso wie in jedem anderen Grafikchip bearbeitet, sprich durch die Vertexshader gejagt und anschließend den Tiles zugeordnet. Tiling ist Culling, sprich was nicht in die Tiles passt oder zu klein ist, wird sofort verworfen.
AFAIK kommen in der Displayliste(n) weniger als die Hälfte der Dreiecke an, was schon einen wesentlicher Beitrag des TA darstellt.
Der Zugewinn wird bei heutiger Grafik einfach zu schlecht sein. Einen Ambient Pass muss ich eh machen, dabei kann ich auch gleich den Z-Buffer auslegen. Und bei jedem weiteren Pass verwerfen mir early-Z Techniken die Pixel. Da lohnt es sich einfach nicht mehr auf einen TBR zu setzen.

loewe

2008-06-15, 10:08:33

Der Zugewinn wird bei heutiger Grafik einfach zu schlecht sein. Einen Ambient Pass muss ich eh machen, dabei kann ich auch gleich den Z-Buffer auslegen. Und bei jedem weiteren Pass verwerfen mir early-Z Techniken die Pixel. Da lohnt es sich einfach nicht mehr auf einen TBR zu setzen.

w.z.b.w. (Was zu beweisen wäre!) :)
Sicher sind die heutigen IMRs hoch effiziente Grafikchips, das ist aber SGX auch. Es wird schon Gründe geben warum NV und ATI im mobilen Bereich bisher keinen Boden gegen PowerVR gut machen konnten.

Mit SGX 545 hat PowerVR einen DX10.1 Core in der Pipeline, der zwar sehr klein ist mit nur 4 Pipes, aber vom Feature-Set vollständig. Ich denke wir werden noch mal die Gelegenheit erhalten, die verschiedenen Ansätze gegen einander antreten zu lassen.

Gast

2008-06-15, 10:50:33

Es wird schon Gründe geben warum NV und ATI im mobilen Bereich bisher keinen Boden gegen PowerVR gut machen konnten.
Weil da die Software noch nicht so stark versucht den Overdraw drücken. Auch im PC Bereich hat sich das erst die letzten Jahren extrem durchgesetzt. Zudem haben im Mobilbereich TBDRs einen ansehnlichen Marktanteil. Da kann man es Programmiern nicht verübeln es dem Grafikchip zu überlassen.

Gast

2008-06-15, 11:05:31

Zudem haben im Mobilbereich TBDRs einen ansehnlichen Marktanteil. Da kann man es Programmiern nicht verübeln es dem Grafikchip zu überlassen.

gerade im mobilen bereich muss man auch heute noch so viel leistung wie möglich sparen, auch auf einem TBDR ist es deutlich besser wenn ein nicht sichtbares polygon erst garnicht zur GPU kommt.
auch ein TBDR kann bei einem verdeckten polygon "nur" das pixelshading einsparen.

Gast

2008-06-15, 14:41:28

gerade im mobilen bereich muss man auch heute noch so viel leistung wie möglich sparen, auch auf einem TBDR ist es deutlich besser wenn ein nicht sichtbares polygon erst garnicht zur GPU kommt.
auch ein TBDR kann bei einem verdeckten polygon "nur" das pixelshading einsparen.
Z-First oder alles in der Richtung hat halt einen gewissen Overhead. Ist der im Vergleich zu den restlichen Kosten zu hoch (bis vor max 5 Jahren auf dem PC + heutige Mobiles) dann macht man es einfach nicht. Für heutige PC+stationäre Konsolen ist er Overhead aber so gering und der Z-Pass für viele Rendertechniken eh notwendig, dass ein TBDR Renderer hier nichts mehr holen kann.

Coda

2008-06-15, 15:28:47

loewe

2008-06-15, 18:18:25

Ich glaube auch, dass die Zeiten in denen ein TBDR einen wesentlichen Vorteil bringen könnte vorbei sind.

Erstens durch das ganze Z-First-Zeug (wo man noch ein wenig Bandbreite sparen könnte, aber davon haben wir heute genug) und zweitens weil pure Rechenleistung immer wichtiger wird.

Wir sollten sicher die PowerVR Cores nicht ausschließlich auf die Vermeidung von Overdraw reduzieren, da kommt doch noch ein wenig mehr zusammen, so dass im ganzen eine recht effiziente Architektur entsteht. Wenn ich damit irgendwo mit 400 Mill. Transistoren das bringen kann, was andere mit 500 Mill. schaffen, halte ich das schon für einen Vorteil.

Ich sehe aber noch einen anderen Vorteil. Die SGX Cores von PowerVR sollten nahezu beliebig scaliert werden können. Wenn ein Core zu schwach, dann nimmt man eben einen zweiten dazu, oder 4 oder auch 16 oder was auch immer. Jeder Core berechnet seinen rechteckigen Ausschnitt der Szene, alles was er wissen muss ist, welcher Teil das ist.
Das was mit Macro-Tiling auf einem Core geht, sollte auch mit vielen problemlos möglich sein.

del_4901

2008-06-15, 19:46:28

Wir sollten sicher die PowerVR Cores nicht ausschließlich auf die Vermeidung von Overdraw reduzieren, da kommt doch noch ein wenig mehr zusammen, so dass im ganzen eine recht effiziente Architektur entsteht. Wenn ich damit irgendwo mit 400 Mill. Transistoren das bringen kann, was andere mit 500 Mill. schaffen, halte ich das schon für einen Vorteil. Ja mit welcher Software? Der Molbile Mark z.B verwendet einfach archaische Techniken, das ist nichtmehr State of the Art. Sobald man da ein paar moderne Posteffekte drüberhaut, wie z.B SSAO kann SGX einfach keinen Vorteil für sich verbuchen. Der einzige Vorteil für SGX liegt im ersten Render Durchgang, und für jede Shadowmap Generierung. Letzteres macht man aber nicht so häufig, Und dann hat NV auch noch diese hässliche Technik wo man echt viele Z-Samples schreiben kann. Da fehlt es SGX und Konsorten dann wieder an der Rohleistung. Letztenendes ist es einfach ne Nullrunde, die sich nur im Mobile Segment lohnt, und dort auch nur solange bis die SW von heute auch dort angekommen ist.

Das was mit Macro-Tiling auf einem Core geht, sollte auch mit vielen problemlos möglich sein.
Lehn dich da mal nicht zuweit aus dem Fenster, SFR und ähnliche Techniken, die an einem Bild arbeiten, sind nicht ohne Grund tot.

loewe

2008-06-15, 20:35:20

Ja mit welcher Software? Der Molbile Mark z.B verwendet einfach archaische Techniken, das ist nichtmehr State of the Art. Sobald man da ein paar moderne Posteffekte drüberhaut, wie z.B SSAO kann SGX einfach keinen Vorteil für sich verbuchen. Der einzige Vorteil für SGX liegt im ersten Render Durchgang, und für jede Shadowmap Generierung. Letzteres macht man aber nicht so häufig, Und dann hat NV auch noch diese hässliche Technik wo man echt viele Z-Samples schreiben kann. Da fehlt es SGX und Konsorten dann wieder an der Rohleistung. Letztenendes ist es einfach ne Nullrunde, die sich nur im Mobile Segment lohnt, und dort auch nur solange bis die SW von heute auch dort angekommen ist.
Nun ja, es gibt zwar nur kleine SGX Cores und ich glaube auch nicht das PowerVR überhaupt am Markt der PC Grafik interessiert ist, aber ich würde nie soweit gehen zu sagen die Technologie dahinter ist Mist.
Ich bin davon überzeugt das SGX mit der aktuellen Grafiktechnologie problemlos mithalten kann, sie bauen halt nur kleine Cores.
AFAIK hat jede Pipe eines SGX Cores zwie ALUs mit je vier Hardware Threads, die je vier Datensätze gleichzeitig bearbeiten können. Jeder Pipe wird dann je nach Verwendung eine oder mehrere Textureinheiten zugeordnet (die Anzahl ist nicht gleich bei den verschiedenen Cores), so schlecht kommt mir das gar nicht vor.
Das muss man jetzt "nur noch" entsprechend scalieren und schnell takten, dann sieht das NV oder ATI recht ähnlich.
Wie schon gesagt, ich bin kein Profi, aber das das technologisch im Rückstand sein soll, möchte ich bezweifeln.
Lehn dich da mal nicht zuweit aus dem Fenster, SFR und ähnliche Techniken, die an einem Bild arbeiten, sind nicht ohne Grund tot.
Ich weiß zwar überhaupt nicht was SFR ist :), aber wenn jedes Macro-Tile praktisch mit seiner eigenen Displayliste arbeit, was sie gar nicht müssen, sind sie völlig unabhängig von einander. Genauer gesagt arbeiten dann hier mehrere Cores an mehreren Bildern. Jeder hat seine Dreiecke und muss sie völlig unabhängig von allen anderen in Pixel eines anderen Framebuffer-Bereiches verwandeln.