spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

[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?

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.

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.

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.

"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.

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.

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

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.

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.