PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : DrawElements langsamer als Immediate Mode?


Che
2003-03-08, 15:58:09
Nachdem ich mich endlich ein bisschen mit Vertex Arrays beschäftigt habe, mache ich folgende Entdeckung: glDrawElemnts ist langsamer als glBegin/glEnd.

Ich habe diesen Code:

glBegin(GL_TRIANGLE_FAN);
for (int i=0; i<10; i++)
{
glMultiTexCoord2fvARB(GL_TEXTURE0, Vertex[List[i]].TextureCoord);
glMultiTexCoord2fvARB(GL_TEXTURE1, Vertex[List[i]].TextureCoord);
glVertex3fv(Vertex[List[i]].VertexCoord);
}
glEnd();

durch diesen

glDrawElements(GL_TRIANGLE_FAN,10,GL_UNSIGNED_INT,List);

ersetzt. Mit glbegin läufts zwar auch schon langsam (-> nix T&L Graka), aber immerhin sind noch 15-20 fps drin.
Mit DrawElements ist er permanent auf 1 fps herunten, und das auch nur weil nicht weniger geht :D
Irgendwelche Ideen?

micki
2003-03-08, 19:01:42
manche karten können nur unsigned short und nicht int.. ich glaube geforce1/2t eine davon.

MfG
micki

zeckensack
2003-03-08, 19:20:17
1)Wieviele Vertices sind in deinem Vertex Array?

2)Wie sieht dein Vertex layout aus? Optimal für diesen Fall iststruct Vertex
{
float tex0_x,tex0_y;
float tex1_x,tex1_y;
float cx,cy,cz;
};


3)@micki,
UNSIGNED_INT ist auf NV-Karten AFAIK kein Problem. Auf Voodoos dagegen sehr wohl.
@Che,
Voodoo? :naughty:

Che
2003-03-08, 21:06:52
Originally posted by zeckensack
1)Wieviele Vertices sind in deinem Vertex Array?

2)Wie sieht dein Vertex layout aus? Optimal für diesen Fall iststruct Vertex
{
float tex0_x,tex0_y;
float tex1_x,tex1_y;
float cx,cy,cz;
};


3)@micki,
UNSIGNED_INT ist auf NV-Karten AFAIK kein Problem. Auf Voodoos dagegen sehr wohl.
@Che,
Voodoo? :naughty:


ad 1: ca. 16.000

ad 2:

struct VERTEX
{
float VertexCoord[3];
float TextureCoord[2];
};


ad 3:
Allerdings Voodoo, wehe irgendwer sagt was dummes :devil:
Hab ich geändert auf unsigned short, nützt aber nix... ???

zeckensack
2003-03-08, 22:12:29
Originally posted by Che

struct VERTEX
{
float VertexCoord[3];
float TextureCoord[2];
};
???
Du benutzt doch Multitexturing ... wo ist der zweite Satz Texturkoordinaten?

ad 3:
Allerdings Voodoo, wehe irgendwer sagt was dummes :devil:
Hab ich geändert auf unsigned short, nützt aber nix... ??? Sorry, nach genauerem Nachdenken war meine Aussage oben Quatsch, denn:
Bei Software-Transformation sind diese Sachen komplett Wumpe. Der Treiber muß sich nur schön linear durch das Array durchsaugen können (für bestmögliche Nutzung der Speicherbandbreite). Ergo ist auch die Array-Größe egal. Die spielt erst bei HW-Transformation eine Rolle (weil dort Geometriedaten auf die Karte geschickt werden können und man möglichst wenig überflüssige Daten übertragen will).

Ich habe irgendwie so das Gefühl, daß deine beiden Codeschnipsel nicht äquivalent sind.

glMultiTexCoord2fvARB(GL_TEXTURE0, Vertex[List[i]].TextureCoord);
<...>
glVertex3fv(Vertex[List[i]].VertexCoord);

Du benutzt dort ja quasi mehrere Indizes, einen pro Texturkoordinatensatz, und einen pro Geometriekoordinate. Das ist geschummelt!
Darf man fragen, ob du zufällig mehrere tausend Würfel mit identischen Texturkoordinaten renderst? :naughty:

Che
2003-03-08, 22:28:28
Jup, ich verwende für beide Texturen dieselben Koordinaten, einmal ganz normal für die Basistextur und einmal skaliert für die Deatiltextur. (Texturmatrix sei dank) Ist das etwa "schlechter Stil"? Ich habe zwischen vorskalierten Koordinaten und skalierung mittels Texturmatrix keinen Geschwindigkeitsunterschied gestgestellt, also hab ich mir einen zweiten Satz Texkoords gespart...

Ich habe irgendwie so das Gefühl, daß deine beiden Codeschnipsel nicht äquivalent sind.
...
Du benutzt dort ja quasi mehrere Indizes, einen pro Texturkoordinatensatz, und einen pro Geometriekoordinate. Das ist geschummelt!

Hmmm?? Die Indizes sind für Textur- und Geometriekoordinaten gleich. Konkret sieht das ganze so aus:


int List[10];
<Liste zusammenstellen>

glBegin(GL_TRIANGLE_FAN);
for (int i=0; i<10; i++)
{
glMultiTexCoord2fvARB(GL_TEXTURE0, Vertex[List[i]].TextureCoord);
glMultiTexCoord2fvARB(GL_TEXTURE1, Vertex[List[i]].TextureCoord);
glVertex3fv(Vertex[List[i]].VertexCoord);
}
glEnd();

Che
2003-03-08, 22:38:39
Jup, ich verwende für beide Texturen dieselben Koordinaten, einmal ganz normal für die Basistextur und einmal skaliert für die Deatiltextur. (Texturmatrix sei dank) Ist das etwa "schlechter Stil"? Ich habe zwischen vorskalierten Koordinaten und skalierung mittels Texturmatrix keinen Geschwindigkeitsunterschied gestgestellt, also hab ich mir einen zweiten Satz Texkoords gespart...

Ich habe irgendwie so das Gefühl, daß deine beiden Codeschnipsel nicht äquivalent sind.
...
Du benutzt dort ja quasi mehrere Indizes, einen pro Texturkoordinatensatz, und einen pro Geometriekoordinate. Das ist geschummelt!

Hmmm?? Die Indizes sind für Textur- und Geometriekoordinaten gleich. Konkret sieht das ganze so aus:


int List[10];
<Liste zusammenstellen>

glBegin(GL_TRIANGLE_FAN);
for (int i=0; i<10; i++)
{
glMultiTexCoord2fvARB(GL_TEXTURE0, Vertex[List[i]].TextureCoord);
glMultiTexCoord2fvARB(GL_TEXTURE1, Vertex[List[i]].TextureCoord);
glVertex3fv(Vertex[List[i]].VertexCoord);
}
glEnd();


Die Schleife habe ich durch DrawElements() ersetzt. Was vielleicht noch wichtig ist, das ganze spielt sich innerhalb eines Quadtrees ab, in jeder Node wird eine neue Liste zusammengestellt und dann diese Liste gezeichnet, insgesamt komme ich auf 800-1000 Nodes. Zuerst dachte ich 1000 Aufrufe von DrawElements drücken die performance, aber ob ich 1000 mal glBegin/end aufrufe oder 1000 mal DrawElements müsste doch im schlimmsten Fall keinen Unterschied machen, im besten Fall müsste DrawElements deutlich schneller sein.


@ zeckensack:
Natürlich darfst du fragen. Das ganze ist eine schöne Landschaft, die aus lauter kleinen Fans besteht. Im Hintergrund läuft ein Quadtree, im Vordergrund ein entfernungsabhängiges LOD System, drumherum eine hübsche Skybox...eben alles was das Programmierherz erfreut :)

Zum Schluss noch eine kleine Nebenfrage

Der Treiber muß sich nur schön linear durch das Array durchsaugen können

Heißt das etwa das die Indizes möglichst aufeinanderfolgend sein sollen z.b 10,11,12,13,14,15...? Eine typische Liste sieht bei mir nämlich so aus:
64,0,32,128,75,55,84,12,5...
Ist das das Problem?

Che
2003-03-08, 22:39:28
Doppelpost?

Che
2003-03-14, 18:38:45
Hab ein bisschen herumgespielt:

16.000 Vertices mit DrawElements: 28 fps
16.000 Vertices mit glBegin/End: 28 fps
(Indexliste: 0,128,1,129,2,130,3,131,4....)

1 Dreieck (3 Vertices) mit DrawElements: 300 fps
1 Dreieck (3 Vertices) mit glBegin/End: 300 fps
(Indexliste: 0,128,1)

1 Dreieck mit DrawElements 4000 mal (Schleife, 4000 mal DrawElements aufgerufen , 12.000 Vertices): 5 fps
1 Dreieck mit glBegin/End 4000 mal (Schleife, 4000 mal glBegin/End aufgerufen , 12.000 Vertices): 10 fps

??? Ich kapier das nicht...

stabilo_boss13
2003-03-14, 19:07:49
Originally posted by Che
1 Dreieck mit DrawElements 4000 mal (Schleife, 4000 mal DrawElements aufgerufen , 12.000 Vertices): 5 fps
1 Dreieck mit glBegin/End 4000 mal (Schleife, 4000 mal glBegin/End aufgerufen , 12.000 Vertices): 10 fps
??? Ich kapier das nicht... Hast du eigentlich einen Profiler?
Dann könntest du exakt feststellen, wo du die Zeit verlierst.

zeckensack
2003-03-14, 19:14:24
Originally posted by Che
Hab ein bisschen herumgespielt:

16.000 Vertices mit DrawElements: 28 fps
16.000 Vertices mit glBegin/End: 28 fps
(Indexliste: 0,128,1,129,2,130,3,131,4....)

1 Dreieck (3 Vertices) mit DrawElements: 300 fps
1 Dreieck (3 Vertices) mit glBegin/End: 300 fps
(Indexliste: 0,128,1)

1 Dreieck mit DrawElements 4000 mal (Schleife, 4000 mal DrawElements aufgerufen , 12.000 Vertices): 5 fps
1 Dreieck mit glBegin/End 4000 mal (Schleife, 4000 mal glBegin/End aufgerufen , 12.000 Vertices): 10 fps

??? Ich kapier das nicht...
Wenn du die Texturkoordinaten im "glBegin/glEnd"-Fall immer noch per glMultiTexCoord2fvARB aus dem gleichen Speicher holst, dann könnte das bereits auf eine Speicherlimitierung bei DrawElements hinweisen. Dort sind die Daten ja verdoppelt, ergo benötigen sie mehr Bandbreite, und passen uU nicht mehr in den Prozessor-Cache.

Für einen fairen Vergleich solltest du die Daten auch bei glBegin/glEnd verdoppeln. Für's Rendering selbst wäre es wiederum Unsinn, auf diesen Performancegewinn zu verzichten. Dies soll nur zum Verständnis dienen :)

Unregistered
2003-03-14, 19:35:32
Originally posted by zeckensack

Wenn du die Texturkoordinaten im "glBegin/glEnd"-Fall immer noch per glMultiTexCoord2fvARB aus dem gleichen Speicher holst, dann könnte das bereits auf eine Speicherlimitierung bei DrawElements hinweisen. Dort sind die Daten ja verdoppelt, ergo benötigen sie mehr Bandbreite, und passen uU nicht mehr in den Prozessor-Cache.

Für einen fairen Vergleich solltest du die Daten auch bei glBegin/glEnd verdoppeln. Für's Rendering selbst wäre es wiederum Unsinn, auf diesen Performancegewinn zu verzichten. Dies soll nur zum Verständnis dienen :)

hmmm? Das versteh ich nicht ganz. Wieso doppelte Datenmenge? Werden die Daten bei diesem Code

glClientActiveTextureARB(GL_TEXTURE0_ARB);
glTexCoordPointer(2, GL_FLOAT, sizeof(VERTEX), testarray[0].TextureCoord);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

glClientActiveTextureARB(GL_TEXTURE1_ARB);
glTexCoordPointer(2, GL_FLOAT, sizeof(VERTEX), testarray[0].TextureCoord);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

tatsächlich doppelt angelegt?
Wenn ja wäre das zwar dumm (identische Daten doppelt vorhanden), täte aber auch nix ändern weil ich beim testen kein Multitexturing benutzt habe.

Originally posted by stabilo_boss13
Hast du eigentlich einen Profiler?
Dann könntest du exakt feststellen, wo du die Zeit verlierst.

Profiler... Kenn ich vom hörensagen :D
Ich benutze vc++6.0, ist da so ein Teil dabei? Wenn ja wie benutze ich es?

stabilo_boss13
2003-03-14, 19:39:11
Originally posted by Unregistered
Profiler... Kenn ich vom hörensagen :D
Ich benutze vc++6.0, ist da so ein Teil dabei? Wenn ja wie benutze ich es? Ja, ist dabei. Wenigstens in der Professional und Enterprise Edition.
Das HowTo gibt es hier:
http://msdn.microsoft.com/library/default.asp?URL=/library/devprods/vs6/visualc/vccore/_core_profiling.3a_.overview.htm

zeckensack
2003-03-14, 19:43:05
Ach so! :idea:
Originally posted by Unregistered
hmmm? Das versteh ich nicht ganz. Wieso doppelte Datenmenge? Werden die Daten bei diesem Code

glClientActiveTextureARB(GL_TEXTURE0_ARB);
glTexCoordPointer(2, GL_FLOAT, sizeof(VERTEX), testarray[0].TextureCoord);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

glClientActiveTextureARB(GL_TEXTURE1_ARB);
glTexCoordPointer(2, GL_FLOAT, sizeof(VERTEX), testarray[0].TextureCoord);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

tatsächlich doppelt angelegt?
Wenn ja wäre das zwar dumm (identische Daten doppelt vorhanden), täte aber auch nix ändern weil ich beim testen kein Multitexturing benutzt habe.Nein. Sie werden tatsächlich nicht verdoppelt. Die gl*Pointer-Funktionen manipulieren niemals deine Daten.

Allerdings gibt mir das Anlaß, meine Meinung um 180° zu wenden :D
Das Problem könnte in der Tat eben dieses sein, daß die Daten nicht doppelt vorhanden sind. Die Durchschnittliche OGL-Implementierung rechnet wohl kaum damit, daß zweimal pro Vertex die gleichen Daten referenziert werden. Im Grunde sollte man davon nur auf HW-T&L-Karten etwas merken, aber den Versuch solltest du ruhig mal unternehmen. Der Voodoo-Treiber ist ja schon recht oll auf der Brust ...

Che
2003-03-14, 20:11:18
Auch mit getrenneten Arrays bleibt alles beim alten. (i.e. kein Geschwindigkeitsunterschied)

Was mich bei der ganzen Sache so wundert ist dass bei häufigen Aufrufen (>2000) von DrawElements die Performance in den keller geht. Und ich dachte immer die Daten in einem Rutsch an die graka zu schicken (=DrawElements) ist in jedem Fall schneller als jeden Vertex einzeln zu senden(=glBegin/End) ?-)
Das Phänomen tritt nur auf wenn ich meine Geometrie folgendermaßen rendere: Viele Aufrufe von DrawElements mit jeweils wenigen Elementen. Umgekehrt (wenige Aufrufe von DrawElements mit jeweils vielen Vertices) gibt's keine Probleme.
Jeder "Sortierbaum" (->Quake style BSP) liefert doch am Ende eine Menge Nodes (oder eben Leafs) mit jeweils ein paar Polygonen, d.h. man kommt um viele Aufrufe von DrawElements nicht herum...Und Quake 3 läuft bei mir flüssig.
JC hat anscheinend doch mehr drauf als ich :D

Thx @ stabilo, für link
und Thx @ zeckensack für die unermüdlichen Erklärungen :flower:

Pitchfork
2003-03-14, 23:58:52
Anmerkung zum Thema Renderaufrufe und Vertices. Unter DX gilt die Faustformel:

Bei 1 GHz Prozessorspeed und voller Prozessorlast sind 25000 DrawPrimitive pro Sekunde möglich. Egal wieviele Verts da behandelt werden.
Dieser Wert skaliert ausschließlich mit der Prozessorleistung. Für OpenGL liegt er etwas höher, aber nicht wesentlich.

Also niemals nen BSP Tri für Tri abrendern!

Che
2003-03-15, 17:10:59
Originally posted by Pitchfork
Anmerkung zum Thema Renderaufrufe und Vertices. Unter DX gilt die Faustformel:

Bei 1 GHz Prozessorspeed und voller Prozessorlast sind 25000 DrawPrimitive pro Sekunde möglich. Egal wieviele Verts da behandelt werden.
Dieser Wert skaliert ausschließlich mit der Prozessorleistung. Für OpenGL liegt er etwas höher, aber nicht wesentlich.

Also niemals nen BSP Tri für Tri abrendern!

Ich nehm mal an DrawPrimitive ist das Gegenstück zu DrawElements. d.h. mit meinen 550 MHZ sollten die getesteten 4000 Aufrufe noch nicht limitieren, eher das Software T&L für die vielen Verts...Dann wunderts mich aber dass ich bei einem Aufruf á 16.000 Verts noch fast 30 fps gebacken bekomm und bei 4000 Aufrufen á 3 Vertices ("nur" 12.000 Verts) nix mehr geht.

Schön langsam glaube ich mein DrawElements ist kaputt :D

@Pitchfork: Wie rendere ich denn einen BSP sonst? Durchlaufen bis in ein Leaf und die dort vorhandenen Dreicke zeichnen...Und bei 5000 Leafs habe ich eben 5000 mal DrawElements.

Demirug
2003-03-15, 17:29:34
Originally posted by Che


Ich nehm mal an DrawPrimitive ist das Gegenstück zu DrawElements. d.h. mit meinen 550 MHZ sollten die getesteten 4000 Aufrufe noch nicht limitieren, eher das Software T&L für die vielen Verts...Dann wunderts mich aber dass ich bei einem Aufruf á 16.000 Verts noch fast 30 fps gebacken bekomm und bei 4000 Aufrufen á 3 Vertices ("nur" 12.000 Verts) nix mehr geht.

Schön langsam glaube ich mein DrawElements ist kaputt :D

@Pitchfork: Wie rendere ich denn einen BSP sonst? Durchlaufen bis in ein Leaf und die dort vorhandenen Dreicke zeichnen...Und bei 5000 Leafs habe ich eben 5000 mal DrawElements.

Bei DX werden alle Calls die letzendlich das Render auslösen als DrawPrimitive Calls bezeichnet. Es gibt davon aber mehrer abarten.

- DrawPrimtive
- DrawIndexedPrimtive
- DrawPrimtiveUP
- DrawIndexedPrimtiveUP

Die UP (User Pointer) versionen kommen DrawElements am nächsten. Allerdings sind die UP Varianten als langsam bekannt.

Beim Render gilt es zwei Grundsätze:

- Vermeide Datenbewegungen
- Vermeide Calls in die API

Also Renderstates (zB. Texturen) so selten wie möglich ändern und Geometrie in einem Buffer sammeln und mit einem Call übergeben.

Unregistered
2003-03-15, 18:07:00
Originally posted by Demirug
...Geometrie in einem Buffer sammeln und mit einem Call übergeben.

Also tatsächlich die ganze geometrie durchlaufen, eine Liste basteln und dann erst an die Graka schicken...ist das nicht recht prozessorlastig?

Demirug
2003-03-15, 18:23:49
Originally posted by Unregistered


Also tatsächlich die ganze geometrie durchlaufen, eine Liste basteln und dann erst an die Graka schicken...ist das nicht recht prozessorlastig?

Es belastet den Processor weniger als für jeweils ein paar Dreiecke DrawElement aufzurufen. Das hängt damit das man für jeden DrawElement Call einen bestimmten (hängt vom Treiber und Hardware ab) Overhead bekommt der unabhängig von der Anzahl der Dreiecke ist. Und dieser Overhead kann recht gross sein.

Pitchfork
2003-03-15, 18:55:15
Am schnellsten ist es, den BSP völlig aus der Renderlogik rauszunehmen. BSP ist für Collisiondetection uns so vielleicht noch ne nützliche Technik, aber zum Rendern völlig veraltet. Fasse einfach im Editor die Räume zusammen und render immer einen Raum am Stück.

Che
2003-03-19, 19:06:48
Tja, dann werde ich die Architektur des ganzen Prokektes wohl komplett neu überdenken. Zur Zeit verwende ich einen Quadtree und ein entfernungsabhängiges LOD um das Terrain zu rendern, so dass ich am Ende mit lauter kleinen Fans dastehe. Nun hat sich gezeigt dass das vielleicht nicht unbedingt die beste Idee ist -> relativ prozessorlastig. Für mein System (non HW T&L, 550Mhz) ist's ideal da hier das einsparen von Vertices im Vordergrund steht und die Prozessorleistung die für die "Spar-Algorithmen" draufgeht weitaus geringer ist als die Leistung die für die Berechnung von zusätzlichen Dreicken benötig würde. Eine T&L Karte würde die Geometrie wahrscheinlich viel schneller verarbeiten können als mein Algorithmus sie bereitstellt...Also zurück zum BruteForce-Ansatz ?
Oder vielleicht das LOD auf 32x32 o. 64x64 Blöcke beschränken?
Irgendwelche Ideen was sich am besten eignen würde?

Che
2003-03-19, 19:09:17
btw: Was ist denn das ARB_vertex_buffer_object von dem zeckensack in einem anderen Thread hier berichtet, klingt ganz brauchbar...aber wird nur von neuen Grakas unterstützt, oder?

zeckensack
2003-03-19, 22:31:20
Originally posted by Che
btw: Was ist denn das ARB_vertex_buffer_object von dem zeckensack in einem anderen Thread hier berichtet, klingt ganz brauchbar...aber wird nur von neuen Grakas unterstützt, oder? Ist eine herstellerübergreifende ( <= endlich ...) Extension, um Geometriedaten in den Grafikkartenspeicher zu schieben.

1)Macht nur bei HW-T&L überhaupt Sinn ;)
2)Gibt's auch bei aktuellen Karten bisher nur in Dev-Betatreibern. Ganz frisch verabschiedet.

zeckensack
2003-03-19, 22:33:11
Originally posted by Che
Tja, dann werde ich die Architektur des ganzen Prokektes wohl komplett neu überdenken. Zur Zeit verwende ich einen Quadtree und ein entfernungsabhängiges LOD um das Terrain zu rendern, so dass ich am Ende mit lauter kleinen Fans dastehe. Nun hat sich gezeigt dass das vielleicht nicht unbedingt die beste Idee ist -> relativ prozessorlastig. Für mein System (non HW T&L, 550Mhz) ist's ideal da hier das einsparen von Vertices im Vordergrund steht und die Prozessorleistung die für die "Spar-Algorithmen" draufgeht weitaus geringer ist als die Leistung die für die Berechnung von zusätzlichen Dreicken benötig würde. Eine T&L Karte würde die Geometrie wahrscheinlich viel schneller verarbeiten können als mein Algorithmus sie bereitstellt...Also zurück zum BruteForce-Ansatz ?
Oder vielleicht das LOD auf 32x32 o. 64x64 Blöcke beschränken?
Irgendwelche Ideen was sich am besten eignen würde? Wieviele Vertices sind in den einzelnen Nodes? Kannst du das variiern?
Mit HW-T&L lohnt es sich kaum, weniger als 100 Dreiecke in einem Rutsch zu malen ... besser wären 1000.

Che
2003-03-20, 18:07:07
Originally posted by zeckensack
Wieviele Vertices sind in den einzelnen Nodes? Kannst du das variiern?
Mit HW-T&L lohnt es sich kaum, weniger als 100 Dreiecke in einem Rutsch zu malen ... besser wären 1000.

Zwischen 5 und 10...also völlig unterdimensioniert für HW T&L. Aber auch wenn ich das Gekände zwecks LOD in zB 32x32 Blöcke aufteile und Strips benutze habe ich nur 64 Vertices pro Aufruf, weil ich ja für jede "Zeile" einen neuen Strip anfangen muss. Die einzige Möglichkeit die ich sehe um wirklich viele Vertices pro Aufruf zu bekommen wäre das ganze Gelände wirklich mit Dreiecken (GL_TRIANGLES) zu rendern, aber da sende ich ja jeden Vertex doppelt und dreifach durch die Pipeline was auch nicht gerade wünschenswert ist.
Kann man mit Strips eigentlich "Ecken" zeichnen:


----> ----> |
x---x---x---x---x |
| / | / | / | / | |
|/ |/ |/ |/ | V
x---x---x---x---x
| / | |
|/ | |
x---x |
| / | V
|/ |
x---x
. |
. |
. |
. . . . . V
<--- <--- <---

Sollte doch möglich sein. Dann könnte man allerdings auch mit Strips viele Vertices auf einmal zeichnen...

Originally posted by zeckensack
Macht nur bei HW-T&L überhaupt Sinn

Eine neue Grafikkarte muss her, am besten eine R9500 Pro..........für meinen PIII 550 :D

zeckensack
2003-03-20, 18:35:36
Originally posted by Che


Zwischen 5 und 10...also völlig unterdimensioniert für HW T&L. Aber auch wenn ich das Gekände zwecks LOD in zB 32x32 Blöcke aufteile und Strips benutze habe ich nur 64 Vertices pro Aufruf, weil ich ja für jede "Zeile" einen neuen Strip anfangen muss. Die einzige Möglichkeit die ich sehe um wirklich viele Vertices pro Aufruf zu bekommen wäre das ganze Gelände wirklich mit Dreiecken (GL_TRIANGLES) zu rendern, aber da sende ich ja jeden Vertex doppelt und dreifach durch die Pipeline was auch nicht gerade wünschenswert ist.
Kann man mit Strips eigentlich "Ecken" zeichnen:


----> ----> |
1---3---x---x---9 |
| / | / | / | / | |
|/ |/ |/ |/ | V
2---x---x---8---11
13 / | |
<= |/ | |
12--10 |
| / | V
|/ |
x---x
. |
. |
. |
. . . . . V
<--- <--- <---

Sollte doch möglich sein. Dann könnte man allerdings auch mit Strips viele Vertices auf einmal zeichnen...Das kann man nur, indem man 'degenerate tris' einfügt, also Schnullidreiecke, die Null Fläche haben. Ohne diese Krücke läßt sich ein einmal angefangener Strip nicht um Ecken biegen. 'Nen Versuch wär's durchaus wert. Ich habe die entsprechende Änderung (die den Strip aber gleich um 180° dreht) oben in dein Diagramm eingefügt. Die Nummern geben die Reihenfolge der Vertices an. Dreieck 9/10/11 ist dabei degenerate. Danach geht's mit korrektem Winding nach links weiter (10/11/12). #13 ist eine Wiederholung von #8.

Eine neue Grafikkarte muss her, am besten eine R9500 Pro..........für meinen PIII 550 :D Knapp OT: ich würde Hobby-Devs dringend ans Herz legen, eine R9600 (pro oder nicht ist wurscht) anzuschaffen, sobald sie verfügbar wird. Ich werd's jedenfalls tun.

F-Buffer ahoi :)

GfFX5200 wäre 'ne Alternative, aber die ist mir einfach nicht geil genug.

zeckensack
2003-03-20, 18:38:20
Originally posted by zeckensack
... mit korrektem Winding ... Sorry, gerade das eben nicht. Ich muß da noch was korrigieren.
*grübel*

Achill
2003-03-20, 19:23:10
ein vorschlag, habe aber kaum ahnung, aber wenn ich es richtig verstanden habe, ein dreieck wird ja immer aus den Vektor x und seinen vorgängern gebildet, (x,x-1x,x-2):


war falsch ...

GL_TRIANGLE_STRIP
Draws a series of triangles (three-sided polygons) using vertices v0, v1, v2, then v2, v1, v3 (note the order), then v2, v3, v4, and so on. The ordering is to ensure that the triangles are all drawn with the same orientation so that the strip can correctly form part of a surface. Preserving the orientation is important for some operations, such as culling. (See "Reversing and Culling Polygon Faces") n must be at least 3 for anything to be drawn.

muss ja beachtet werden...

Demirug
2003-03-20, 19:46:14
Bei einem Gelände sollte man die einzlenen Kacheln (Viereck) in wechselnden Streifen zu rendern.



1. Zeile -> 1 2 3 4 5
2. Zeile <- 10 9 8 7 6
3. Zeile -> 11 12 13 14 15
4. Zeile <- 16 17 18 19 20

und so weiter


um das ganze noch effektiver zu machen sollte man die Zeilen Breite auf die grösse des Post T&L Cache anpassen. Wenn man dann in der Letzten Zeile angekommen ist geht man wieder nach oben und dann wieder nach unten bis man am Ende ist.


1. Zeile -01>-02->03 28->29->30->31->32->33
| | |
2. Zeile 06<-05<-04 27<-26<-25 usw<-34
| |
3. Zeile 07->08->09 22->23->24
| |
4. Zeile 12<-11<-10 21<-20<-19
|
... ...
|
x Zeile 13->14->15->16->17->18

Demirug
2003-03-20, 19:59:19
Please Hang Over Your Bed

25k draws/s @ 100% on 1GHz CPU

Che
2003-03-21, 20:51:22
Holla, viele Anregungen, danke an alle...mal sehen wann ich wieder Zeit habe mich mal ordentlich dahinterzuklemmen.

Nach links weiter geht doch überhaupt nicht mit gleichem Winding, soweit ich das sehe...


Please Hang Over Your Bed

25k draws/s @ 100% on 1GHz CPU

Ich auch, ich auch, bitte irgendwo hochladen, am besten mit Code...*liebschau*


GfFX5200 wäre 'ne Alternative, aber die ist mir einfach nicht geil genug.

:D:D

Demirug
2003-03-21, 21:01:51
Originally posted by Che
Holla, viele Anregungen, danke an alle...mal sehen wann ich wieder Zeit habe mich mal ordentlich dahinterzuklemmen.

Nach links weiter geht doch überhaupt nicht mit gleichem Winding, soweit ich das sehe...

Mit degeneriten Dreiecken kann man notfalls auch das Winding drehen. Zudem gibt es ja immer noch die möglichkeit einen Index Stripe zu benutzten eine Index Trianglelist ist auch nicht schlecht. Für diesen Fall müsste man schauen was besser ist.

Ich auch, ich auch, bitte irgendwo hochladen, am besten mit Code...*liebschau*

Was soll ich da hochlande? Die Zahl habe ich vom NVIDIA Devsupport bekommen.

Xmas
2003-03-21, 22:03:34
Originally posted by zeckensack
Knapp OT: ich würde Hobby-Devs dringend ans Herz legen, eine R9600 (pro oder nicht ist wurscht) anzuschaffen, sobald sie verfügbar wird. Ich werd's jedenfalls tun.

F-Buffer ahoi :)

GfFX5200 wäre 'ne Alternative, aber die ist mir einfach nicht geil genug.
Du meinst R9800. Die 9600 hat keinen F-Buffer. *heul* Eine 9800 kann ich mir nicht leisten und ne kleine FX ist mir auch nicht geil genug...

Che
2003-03-21, 22:25:06
Originally posted by Demirug

Was soll ich da hochlande? Die Zahl habe ich vom NVIDIA Devsupport bekommen.

Und ich hab gedacht du hast da schon was schnelles programmiert...

zeckensack
2003-03-22, 20:25:29
Originally posted by Demirug
Was soll ich da hochlande? Die Zahl habe ich vom NVIDIA Devsupport bekommen. Die Zahl und der Spruch sind wie mir scheint aus diesem frei verfügbaren PDF (http://developer.nvidia.com/docs/IO/4449/SUPP/BatchBatchBatch.pdf).

Btw liegt die Grenze bei OpenGL um ~Faktor 2 höher. Das liegt daran, daß OpenGL-Treiber idR nicht im Kernel-Mode laufen und deswegen die Funktionen mit weniger Overhead aufgerufen werden können (kein Wechsel des Prozessor-'Rings').

Demirug
2003-03-22, 21:53:05
Originally posted by zeckensack
Die Zahl und der Spruch sind wie mir scheint aus diesem frei verfügbaren PDF (http://developer.nvidia.com/docs/IO/4449/SUPP/BatchBatchBatch.pdf).

Btw liegt die Grenze bei OpenGL um ~Faktor 2 höher. Das liegt daran, daß OpenGL-Treiber idR nicht im Kernel-Mode laufen und deswegen die Funktionen mit weniger Overhead aufgerufen werden können (kein Wechsel des Prozessor-'Rings').

Man hat es also endlich online gestellt.

Zeckensack, der Wechsel in den Ring 0 ist auch unter OpenGL notwendig. Diesen Wechsel kann sich NVIDIA nur bei der XBox sparen. Unter OpenGL hat man nur wiedermal den Effekt das eine eigene Extension nun mal schneller als eine allgemeine API ist. Zudem hat man bei einem OpenGL Treiber etwas mehr freiheiten was es aber auch für viele IHV scheinbar schwerer macht gute OpenGL Treiber zu schreiben.

zeckensack
2003-03-22, 22:18:22
Das sollte jetzt keineswegs D3D-Bashing sein. Das habe ich aus dem PDF gemopst (Seite 14). Inwiefern diese Aussage allgemeingültig ist muß man natürlich nachprüfen.

Das mit dem Wechsel des Privilegien-Levels ist die klassische Erklärung dieses Phänomens, wobei ich auch zugeben muß, das nicht hinterfragt zu haben.

Aber wie man aus dem PDF sieht: am besten viel am Stück. Wenn man diese Regel befolgt, dann verschwindet auch der (theoretische?) Performanceunterschied zwischen D3D und OpenGL. Insofern lohnt es sich wirklich nicht, darüber zu zanken.

Demirug
2003-03-22, 22:29:42
zeckensack, ich habe es nicht als Bashing verstanden. Mir ging es nur darum das es nicht an einem fehleden Wechsel des Privilegien-Levels liegen kann. Möglicherweise kommt der OpenGL Treiber aber mit weniger Wechsel als der D3D Treiber aus.

Ja das mit dem Batchen predigt NVIDIA ja schon länger.

Pitchfork
2003-03-24, 12:48:14
Also bei der Präsentation dieses Vortrages kam es zu einigem unterhaltsamen Geplänkel von MS und nV/ATI über die Schuld. MS meint, daß mit DX9 ihre Seite der Dinge getan ist und daß die Treiber jetzt nachziehen müßten. Wobei sowas immer sehr humorvoll gesehen werden muß.

Demirug
2003-03-24, 13:20:09
Originally posted by Pitchfork
Also bei der Präsentation dieses Vortrages kam es zu einigem unterhaltsamen Geplänkel von MS und nV/ATI über die Schuld. MS meint, daß mit DX9 ihre Seite der Dinge getan ist und daß die Treiber jetzt nachziehen müßten. Wobei sowas immer sehr humorvoll gesehen werden muß.

Ja ich kenne das. Entwickler unter sich eben. Wobei es sich bei diesen Änderungen in DX9 um Dinge handeln muss die nicht in der offizielen DDK Documentation zu finden sind sondern nur in den spezial Dokumenten für die IHVs zu finden sind (oder ich bin mal wieder blind).