@Lossy: ok, so dachte ich mir das. grentzt nur an Deine vorher Scherzhaft erwähnte eigene Memory-Verwaltung. Deswegen war ich etwas unsicher.

@VP: Mag ja sein dass mit Vertex-Programmen das ganze einfacher ist, jedoch hab' ich keine Lust, für solche kleinigkeiten gleich ein Vertex-Programm mitzuschleifen, welches denn letztendlich au faälteren Grafikkarten oder Karten der MX-Serien von nVidia per Software emuliert wird und somit nicht das schnellste sein dürfte.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Also mich würde das ehrlich gesagt ein wenig sehr wundern. Es handelt sich ja hiebei um einen Block aus dem sich die Karte mit Daten versorgt. Und wenn da zwei Pointer "rein zufällig" übereinander liegen, dann darf die Karte die ja nicht auseinander ziehen. Damit würden ja meine Pointerangaben nicht mehr stimmen.

Allerdings glaube ich nicht, dass es einne solchen großen Unterschied macht, ob er sich die Karte zwei mal aus dem Speicher holt oder ob ich ihm das per VP zwei mal zuweise.

Wenn man die Koordinaten auch im Vertex Program nur einmal einliest und weitergibt und dann im Fragment Program zum Lesen von beiden Texturen benutzt, macht das in diesem Fall schon einen Unterschied aus, weil die Interpolation über das Dreieck nur einmal gemacht werden muß.

Eine andere Frage. Geht bei jemandem mit Radeon Karte ein Vertex Array vom Typ gl_short richtig schnell oder nur im Softwaremodus? Die Dreiecksleistung hängt von der Größe des Vertex Formates ab und deshalb habe ich die Texturekoordinaten auf der GF4 als gl_short gespeichert. In der FAQ ist gl_short mit 4 Komponenten als Format angeben, aber es ist extrem langsamer als gl_float (Faktor 100). Aufgrund der Spezifikation von arb_vbo muß eigentlich außer beim Color Array nur gl_float unterstützt werden.

Bei VBOs habe ich jetzt ein wenig umständlich gedacht. Primär stellen diese ja nur eine Möglichkeit zur Verfügung, Speicher auf der GraKa anzulegen - das heißt in diesem Fall dass es völlig egal ist, was für Daten drinne sind, die können natürlich auch für Texturkoordinaten beliebig recycelt werden, sodass hier ein VP tatsächlich keine Vorteile bringen sollte.

Wenn man normale Vertex Arrays verwendet, spart man sich sich nur den prozeduralen Overhead Unmengen von glVertexxx und glTexCoordxx Kommandos aufrufen zu müssen.
In diesem Fall werden die Texturkoordinaten tatsächlich zweimal aus dem Speicher kopiert, auch wenn zwei mal der selbe Zeiger verwendet wurde.
Ein Vertexprogramm (ich stimme aber zu, es müsste schon hardwareseitig unterstützt werden) wäre hier ziemlich sicher schneller, da die Daten in diesem Fall schon auf der GraKa liegen. Allerdings könnten auch Software-VPs hier schneller sein, da die Programmierer ja niemand zwingt, nur OpenGL Befehle einzusetzen - auch ältere Grafikkarten haben teils interessante Fähigkeiten, die halt nicht immer in OpenGL oder DirectX gekapselt werden (in OpenGL noch eher, da es hier Herstellerextensions gibt).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Meine Güte, habe ich für den vorigen Eintrag jetzt lange gebraucht (Telefon dazwischen). Mit Fragmentprogrammen sollte die Sache tatsächlich wieder anders aussehen, insbesondere als Vertexprogramme VOR der Transformation der Texturkoordinaten stattfinden, Fragmentprogramme danach (obwohl sowohl Texturkoordinatentransformation als auch Interpolation nicht zu sehr ins Gewicht fallen dürften)

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

@Lars :
Glaube du hast da schonmal nach gefragt,aber da hab ich glatt vergessen zu testen.Hab mein Tool das Rohe Vertexdaten,Displaylisten und Vertexarrays miteinander vergleicht (anhand einer Heightmap) grade umgeschrieben und es mal auf meiner R9700 mit Texturkoordinaten als TGLShort statt TGLFloat probiert.Rausgekommen ist dabei folgendes (Geschwindigkeit Vertexarray) :
GL_FLOAT = ~330fps
GL_SHORT = ~340fps
Die Werte unterliegen natürlich der üblichen Schwankung,und ein Umschalten von Hardware auf Software ist anhand der identischen Werte wohl kaum geschehen.Evtl. hab ichs aber auch anders gemacht als du.Ich hab die Texkoords so übergeben :

bzw. so :

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

@SOS: Danke fürs Ausprobieren. Ich habe das ein wenig ungenau beschrieben, aber hast du das Vertex Array auch in einem VBO gespeichert? Ich habe mal bei deiner VBO Demo von glfloat auf glshort umgestellt und die Anzahl der Dreiecke sank von 210 Millionen/sek auf 4,7 Millionen/sek.

Ich habe

durch

ersetzt und das Vertex Format entsprechend angepaßt.

Wenn ich das Texture Koordinaten Array nicht enable steigt die Geschwindigkeit über 230 Millionen Dreiecke.

Hab das jetzt auch mal mit der VBO-Demo nachvollzogen,und tatsächlich fiel der Dreiecksdurchsatz nach dem Wechsel von GL_FLOAT auf GL_SHORT auf magere 4,5 MTris/s.Gehe auch einfach mal davon aus,das sich ATI da stark an die Spezifikationen gehalten haben und sich auch evtl. gedacht haben das eh keiner seine Texturkoordinaten als Ganzzahlen speichert.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Eigentlich müssen sie es ja nicht. Aber wäre trotzdem schön gewesen wenn ich Position,Koordinaten,Normale,Tangente und Farbe in 32 Byte bekommen hätte, weil ja überall steht das man das Format ausrichten soll. Auf der GF4 war es bei mir so, daß die Größe des Vertex gegensätzlich proportional zur Geschwindkeit war. Auf der Radeon habe ich das noch nicht so genau gemessen, aber vermutlich wird es ähnlich sein. Trotzdem Danke für den Hinweis, dann weiß ich das ich da in die Richtung gar nicht mehr weiter probieren muß.

Ne Vertexstruktur mit ner 32-Bit-Ausrichtung wäre natürlich ziemlich optimal.Was mich allerdings wundert,ist die Tatsache das sowohl GLshort und GLushort in der Radeon 9500/9600/9700/9800 OpenGL Programming and Optimization Guide aus dem ATI-SDK als native Formate angegeben werden (egal ob mit voller Reichweite oder normalisiert),und zwar für VAs und VBOs.Evtl. ist das sogar nur ein Treiberbug und du solltest da mal Kontakt zur ATI-Developerrelation (devrel@ati.com) aufnehmen und das klären (die sollen ja recht flott sein).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)