Du bist nicht angemeldet.

Werbeanzeige

Patrick

Alter Hase

Beiträge: 1 264

Wohnort: Düren

Beruf: Fachinformatiker für Anwendungsentwicklung

  • Private Nachricht senden

11

07.10.2005, 22:34

[Edit von Osram]:

Scheisse, ich wollte per "zitieren" antworten und habe statt dessen ohne es zu merken "edit" erwischt. :( :(
Entschuldigung!
Hat Du Deinen Text zufällig noch?

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

  • Private Nachricht senden

12

07.10.2005, 23:15

So, hier jetzt mein Text unter meinem Namen :-/ :

In BoB hat jede Texture eine eindeutige Zahl, tatsächlich sogar jede Datei. Ein Sortieren nach der Textur ist daher also durch den Vergleich von Zahlen zu machen, in unserem Fall sogar nur 16 bit Zahlen. Das spart Speicherbandbreite.

Man sollte die meisten Texturen bei Beginn des Levels laden. Die Zeit dafür (1 x Übertragen per AGP) steht fest und hat mit per-Frame Sortierung nichts zu tun. Selbst wenn man an Sachen wie Terrain Texture denkt, die man wahrscheinlich bei einer langen Wanderung/Flug nachladen muss, so wird man diese typischerweise nur einmal laden bzw jedesmal wenn man an die Stelle in der Welt zurückkommt.
Man will sie aber definitv nicht mehrfach pro Frame laden, und nur das könnte ein sortieren innerhalb des Frames verhindern.

Der Grund das man sortiert ist einfach, dass Operationen wie das Ändern der aktiven Textur viel Zeit kostet, und zwar im Treiber und auf der Graka.

Man sieht ja auch in der Tabelle, dass manche Operationen langsam sind, bei denen gar keine grossen Datenmengen beteiligt sind.
"Games are algorithmic entertainment."

Patrick

Alter Hase

Beiträge: 1 264

Wohnort: Düren

Beruf: Fachinformatiker für Anwendungsentwicklung

  • Private Nachricht senden

13

07.10.2005, 23:24

Osram
Es geht NICHT um das Laden sondern um den Traffic. Generell sind die Texturen im VRAM, ist jedoch dieser Voll beim setzen einer anderen Textur (zuerst wird sie rübergesendet, dann wird erkannt "aha da ist kein platz mehr, also zurück) wird sie wieder zurück gesendet. Dann wird eine andere Textur oder sonst was aus dem VRAM in den Systemram gestopft und dann wieder das selbe prozedere. So kommen locker mehrere MByte Traffic zustande, vorallem bei 2048x2048x32 Texturen + Alphachannels.

Ob man jetzt per Zahl sortiert oder per String ist heutigen CPUs um ehrlich zu sein mehr als nur Scheiß egal. Es geht ganz allein um den Traffic welcher entscheident ist. Die Operationen die Direct3D oder OpenGL verbrät sind um nochmal ehrlich zu sein mehr als trivial. Wer sich daran aufhält optimiert definitiv an der falschen Stelle. Das war vor Jahren als AGP noch nicht da war oder die GraKas zu lam waren von bedeutung, heute ist jedoch nur noch eines relevant: Minimierung des Traffics auf dem BUS zwischen RAM und VRAM über dem AGP.

Da wird auch nicht dran gerüttelt und geschüttelt, das ist so. Texturswitches (und damit meine ich jetzt nicht SetTexture und so) kosten Zeit und das je nach größe und qualität der Bitmap. Ob jetzt ein SetFVF oder ein SetVertexDeclaration lange dauert oder nicht ist furz wie Deckel. Traffic ist heute das Non-Plus-Ultra. Da bringt Dir selbst die Tabelle nichts mehr, denn die beschreibt nicht die Dauer des Transfers und hat mit diesem Thema soviel zutun wie Nicky Lauder mit Gina Wild.

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

  • Private Nachricht senden

14

07.10.2005, 23:57

Zitat von »"Patrick"«


Generell sind die Texturen im VRAM, ist jedoch dieser Voll


Dies sollte soweit wie möglich vermieden werden. Z.B. kann man bei Karten mit kleinem VRAM die Texturauflösung runterrechnen.

Auch von 2k x 2k x 32 bit passen normalerweise etliche in den Speicher. Wenn man DXT Kompression benutzt sind das gerade mal 4 MB. BoB wird jetzt in den USA und UK verkauft und eine für mich überraschende Sache ist, dass wir fast keine 64MB VRAM Nutzer haben, vielleicht 10% und der Rest geht zu ungefähr gleichen Teilen an 128MB und 256 MB. Natürlich muss man auch ein bischen mitdenken und z.B. bei Terraintexturen nicht nur schauen, welche man neu braucht, sondern auch, welche man nicht mehr braucht.

Selbst in dem Fall dass man das nicht macht, wird eine Sortierung nicht nötig sein, um unnötigen AGP Transfer zu vermeiden:
Sagen wir Du hast noch altes Terrain im Speicher und ein neues Monster/Flugzeugtyp kommt an und die Textur passt nicht mehr ins VRAM. Soweit ich weiss, wird "LRU" benutzt um die Texture zu finden, die ausgelagert wird, d.h. die am längsten nicht mehr benutzte Textur. Die Wahrscheinlichkeit, das bei einer weiteren Auslagerung in dem Frame die gerade geladene textur betroffen ist, ist gering. Daher ist - egal ob die Polys sortiert oder nicht sortiert kommen - es nicht nötig, die Textur ein zweites mal in diesem Frame zu übertragen.

Zitat


Ob man jetzt per Zahl sortiert oder per String ist heutigen CPUs um ehrlich zu sein mehr als nur Scheiß egal.


Dem Speicher aber nicht. Kannst ja mal ausrechnen wie viele Vergleichsopertionen per Frame gemacht werden. Ich sag ja auch nicht, dass dies DIE Optimierung ist, die über Wohl oder Wehe entscheidet, aber es ist auch relativ einfach zu implementieren.

Zitat


Es geht ganz allein um den Traffic welcher entscheident ist. Die Operationen die Direct3D oder OpenGL verbrät sind um nochmal ehrlich zu sein mehr als trivial. Wer sich daran aufhält optimiert definitiv an der falschen Stelle.


Nein. Microsoft z.B. macht in DX10 eine Menge Optimierungen, die genau auf die "trivialen" Sachen gehen und den Traffic gar nicht ändern. Z.B. gibt es Texturarrays, d.h. es können mehrere Texturen gleichzeitig aktiv sein und es gibt wenigher "switches". Natürlich sind es immer noch gleich viele Texturdateien und MB, der Traffic wird überhaupt nicht verändert.

Microsoft hat übrigens letztlich zugegeben dass in DX9 der per Objekt Overhead sehr gross ist, und da gehören "switches" von Texturen, Renderstates, Streams etc natürlich dazu. Sie haben gesagt "Das ist in DX10 jetzt 10 mal schneller" :-D

Bei BoB kann man übrigens die AGP Geschwindigkeit mit sehr geringem fps verlust zurückschalten.


Zitat

Da bringt Dir selbst die Tabelle nichts mehr, denn die beschreibt nicht die Dauer des Transfers und hat mit diesem Thema soviel zutun wie Nicky Lauder mit Gina Wild.


Stimmt, die Tabelle hat nichts mit dem Transfer zu tun, deshalb empfinde ich sie ja als so wichtig. :)

Wenn ich fps optimiere, schaue ich mir switches und Sachen wie Overdraw an, aber nicht Transfer.

Wenn ich "Stutter" (einzelne langsame Frames) optimiere, dann ist Traffic tatsächlich eine der wichitgen Sachen.
"Games are algorithmic entertainment."

Patrick

Alter Hase

Beiträge: 1 264

Wohnort: Düren

Beruf: Fachinformatiker für Anwendungsentwicklung

  • Private Nachricht senden

15

08.10.2005, 00:07

"Wenn ich fps optimiere, schaue ich mir switches und Sachen wie Overdraw an, aber nicht Transfer." Tja, super. Bestes Beispiel wo man falsch optimieren kann. Bleib Du ruhig bei Deiner Liste und Deinem BoB, ich bleib bei meinem Kram.

Sorry, aber Zeit verschwenden kann ich auch wenn ich mit einer Wand rede, hat den selben effekt. Gar keinen.

Kurz: Vergiss es einfach. Die Frage des Topics hab ich beantwortet und ende.

rewb0rn

Supermoderator

Beiträge: 2 873

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

16

08.10.2005, 00:10

:(

Patrick

Alter Hase

Beiträge: 1 264

Wohnort: Düren

Beruf: Fachinformatiker für Anwendungsentwicklung

  • Private Nachricht senden

17

08.10.2005, 00:14

Zitat von »"Spik)evil("«

:(
Nee du, sorry, aber was soll ich auf so einen Quatsch antworten? "Kleinere Texturen" - Traffic gibbet da auch und die bomben auch den Ram voll. Dann dieses BoB gelabere. Nee Du sorry, hab echt besseres zu tun, als über so einen (seit Jahren) überholten Nonsens zu diskutieren.

rewb0rn

Supermoderator

Beiträge: 2 873

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

18

08.10.2005, 00:26

Gut also ich kann auf dem Niveau fachlich nicht mithalten, aber ich denke Osram weiß auch, wovon er spricht.

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

  • Private Nachricht senden

19

08.10.2005, 00:37

Zitat


"Kleinere Texturen" - Traffic gibbet da auch


Klar, aber wir sprechen ja in diesem Thread über Sortieren. Und wenn die Textur nur in einem Frame geladen wird, so brauchst Du deshalb nicht in jedem Frame zu sortieren.

Zitat


so einen (seit Jahren) überholten Nonsens zu diskutieren.


Es ist in den letzten Jahren so gewesen, dass die Switches (von Sachen die schon im VRAM sind) wichtiger geworden sind und nicht unwichtiger. Früher war das wichtigste für die Bestimmung der Geschwindigkeit die Zahl der gesetzten Pixel sowie die Zahl der Polygon (bzw. Eckpunkte). Heute ist die Zahl der Objekte bzw DrawIndexedPoly Aufrufe dazugekommen, da ich eben dazwischen typischerweise mehrere "switches" machen muss.
"Games are algorithmic entertainment."

Patrick

Alter Hase

Beiträge: 1 264

Wohnort: Düren

Beruf: Fachinformatiker für Anwendungsentwicklung

  • Private Nachricht senden

20

08.10.2005, 00:43

Zitat von »"Osram"«

Zitat


"Kleinere Texturen" - Traffic gibbet da auch


Klar, aber wir sprechen ja in diesem Thread über Sortieren. Und wenn die Textur nur in einem Frame geladen wird, so brauchst Du deshalb nicht in jedem Frame zu sortieren.
HIMMEL zakramente noch mal! Es geht darum einen SetTexture zu vermeiden!

Nehmen wir an Du hast 4 Objekte:

Objetk 1 hat Textur 1
Objekt 2 hat Textur 2
Objekt 3 hat Textur 1
Objekt 4 hat Textur 2
Objekt 5 hat Textur 1

Wie renderst Du? Wieviele Texturswtiches (Traffic) machst du? 3 oder 2? Pro Frame? Wenn Du nicht sortiest 5 sortierst du: 2. 3 Switches gespart! 3X TRANSFER GESPART FÜR SINNLOSE TEXTURSWITCHES.

Man, bekommste net mit was ich schreibe oder schreib ich zu undeutlich. verdammte axt noch mal? Nebenbei wir reden hier nichtmal über LADEN sondern über SETZEN! Setzen und Laden ist ein unterschied wie Ne Banane und ein Apfel.

Nee also, echt ey, halt ich im Kopf nicht mehr aus.

Werbeanzeige