Ich wollte mich heute mal darum kümmern meine Matrixfunktionen nach Assembler zu portieren, da z.B. das Aktualisieren der Schattenvolumen recht teuer ist (das könnte man zwar recht performant im Shader machen, aber Shader kann nunmal nicht jede Karte). Aber bevor ich mir die Mühe mache, wollte ich mal rundfragen ob jemand von euch das gemacht hat, und v.a. ob die Performance dadurch viel besser wird, oder der Delphicompiler da schon recht fit ist. Ausserdem gibts im integrierten Assembler ja auch die Möglichkeit 3DNow! (bzw. 3DNow!+) zu nutzen, was ja im Endeffekt genau für solche Fälle optimiert sein sollte. Hat das schonmal jemand genutzt, und kann mir da dann auch jemand sagen ob es sich lohnt.

Oder wäre es doch evtl. sinnvoller wirklich Vertexprogramme zu nutzen? Auf alten Karten werden die zwar per Software emuliert, aber der Treiber nutzt dann ja (gehe mal davon aus) trotzdem alles was die CPU hergibt, also MMX/3DNow/SSE, etc.

Wäre über irgendwelche Infos bzg. Geschwindigkeiten unterschiedlicher Implementationen hoch erfreut, denn Testen kann man nur wenn man das alles umstellt, und das ist nicht wenig aufwendig (und im Falle von Assembler auch nicht grade fehlerunanfällig, meine letzten ASM-Erfahrungen liegen Jahre zurück, und dazu noch auf nem x85).

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

soweit ich mich erinnere hatte die GLScene math-Unit relativ viele solche (auch optimierten) und auf 3DNow! ausgelegten funktionen drin...
die könntest du ja evtl. erstmal hernehmen zum testen, ob und wieviel es bringt... :-/

_________________
. . .

Man kann auch die Mathe DLL von Direct3D zusammen mit OpenGL benutzen. Ausprobiert haben ich das aber noch nicht. Das hätte den Vorteil, daß automatisch die gerade eingebaute CPU unterstützt wird.
Die automatische Extrusion im Vertex Shader wurde ja nicht empfohlen, weil man da 3x mehr Dreiecke benötigt als das ursprüngliche Modell. Allerdings dürfte das bei den schnellen Karten heutzutage kein wirkliches Problem sein. Das Modell muß dann halt eben immer wirklich geschlossen sein. Das ist natürlich nicht so toll, wenn man eine Bodenfläche hat und für den Schatten, dann daraus einen Block machen muß.
Immerhin braucht man dann pro Objekt nur noch den IndexBuffer zeichnen und fertig. Ich habe diese Technik früher verwendet, aber nutze im Moment diese halbautomatische Methode, bei der man jeden Vertex 2x, einmal normal und einmal mit w=0, speichert und dann den Indexbuffer anpaßt. Solange sich das Objekt oder Licht nicht bewegt muß man diese Liste ja nicht neu generieren. Dann gibt es da noch Silhoutten Caching. Man geht davon aus, daß sich die Silhouette nur wenig ändert und untersucht nur die Dreiecke in der Nähe der alten Silhouette.
Bei der Demo könntest du auch die Schattenvolumen alle auf die Grundebene projizieren, falls du die diese infinite Schatten Volumen nutzt. Das würde auch eine Menge Füllrate einsparen.
Die Demo läuft bei übrigens mir mit ca 40-50 FPS mit Schatten (Radeon 9800 pro,2000XP+). Das Auto schlingert ein wenig zu stark, aber sonst ist es schon ganz gut spielbar.

http://www.tommesani.com/Exentia.html

Exentia is an open-source library for Delphi, licensed under the Mozilla Public License.
It is designed to perform computations on vectors of 32-bit and 64-bit floating point data elements using the Intel SSE, Intel SSE2, AMD 3D Now! and Intel x87 instruction sets. The library handles the differences among these instruction sets, so that a single code base supports them all.

Hier hats Benchmarks dazu, sieht so aus als koennte man da schon noch einiges herausholen.

http://www.tommesani.com/ExentiaBench.html

Mir geht es im eigentlich darum (GPU stellt für sowas wirklich keine Alternative dar) : Ich habe ja recht viele dynamische Objekte in meiner Szene, und momentan muss ich bei jeder Bewegung (vor der Extrusion) durch alle Vertices des Schattenvolumens gehen und jedes Vertex mit der aktuellen (von Newton zurückgegebenen Matrix) multiplizieren, um die Position des Objektes für die Schattenberechnung zu bekommen. Genau dass dürfte recht aufwendig sein, denn das heisst in Pseudocode :

Was natürlich recht aufwendig ist, zumal die CPU ja eine Allzweckeinheit ist. Allerdings gibts ja so nette Erweiterungen wie MMX (weniger toll) und 3DNow! (Interessanter), mit denen man solche Dinge (zumindest mit letzterem) auch auf der CPU beschleunigen könnte. Deshalb wollte ich wissen ob jemand damit Erfahrungen hat.

Die D3D-Sache spar ich mir vorerst mal, aber schaue mir mal die glScene-Units an, und werde dann mal testen.


@Demo :
Wie gesagt ist die noch sehr CPU-abhängig, da die Newton-Primitiven die ich verwende noch nicht optimiert sind (läuft z.B. auf nem 2,8er + GF4 besser als auf nem 2,0er mit R9800). Aber trotzdem wollte ich generell die Berechnung dynamischer Stencilschatten etwas optimieren.
Und das Projezieren auf die Grundfläche stellt an sich leider keine Alternative dar, da diese Fläche Teil der 3DS-Geometrie ist, und von daher früher oder später verändert wird. Sollte mich auch unbedingt mal darum kümmern dass ich prüfe ob ich nun wirklich zFail oder zPass für ein Volumen brauche, das sollte auch ein wenig Performance bringen.

@Tokter :
Danke für den Link! Hab den leider erste gesehen nachdem du gepostet hast. Werd mir das direkt mal ansehen.

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

Berechne die Silhouette doch im Object Space. Wenn du die Lichtposition mit der inversen Matrix des Objektes transformierst, kannst du auch so die Silhouette berechnen.

Holla! Stimmt ja, das ist eigentlich dass Naheliegenste was man in solch einem Fall tun kann. Danke, k.A. warum ich da nicht draufgekommen bin, werde das aber gleich mal umsetzen.

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

ZFail darf man so eigentlich gar nicht mehr verwenden oder?
Eine freie Alternative ist die andere Variant von Carmack:
1.Pass: back:inc bei zpass und zfail, front: dec bei zpass und zfail
2.Pass: back:dec bei zpass, front: inc bei zpass

Ist nur schlecht, daß es halb so schnell ist, aber bei den meisten Volumen ist ja zpass ausreichend.

Wir sind ja hier immernoch in Europa, und da darf man nicht alles wild und wust patentieren, also von daher egal. Ausserdem muss ich ja nicht sagen das ich zFail benutze...wenn man irgendwann als Privatprogger nicht mehr zFail nutzen darf, spiele ich mal ne Runde RavenShield im Firmengebäude von Creative

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

Sorry for OT, aber sowas fällt dann für mich doch eher unter die Kategorie "sinnloses Trivialpatent", ähnlich dem Doppelklick von Microsoft (das zum Glück sein "Patent" nicht kommerziell verwertet - außer halt für die Gratiswerbung) oder Amazons "One Click" - System. Es ist ja nicht so, dass man dafür nun hochintelligente, schwer nachvollziehbare mathematische Algorithmen (wie etwa diverse Verschlüsselungssysteme) entwickeln musste, es also einem Hobbyprogrammierer völlig unmöglich wäre "zufällig" von selbst drauf zu stoßen und dies anzuwenden.

Topic, auch wenn es sich inzwischen erledigt haben sollte: Eine CPU abhängige Math-Library ist eine Heidenarbeit, da viele CPU Typen unterstützt werden müssten (Intel unterstützt kein 3D-Now, viele AMD Prozessoren kein SSE oder SSE2), und sich das Ganze ohnehin mit der Einführung einer neuen Prozessorgeneration erübrigt. Sinn machen würde für dich meiner Ansicht also wirklich nur die Nutzung einer fertigen Mathlibrary, wie etwa DirectX unter Windows - da ist ja auch nichts Schlechtes dabei, da deine Sounds z.B. über den einen oder anderen Weg wahrscheinlich auch über DirectSound abgespielt werden. Wenn dich DirectX stört, pack das ganze in einen Wrapper, der deine ganzen 3D-Transformationen gebatcht übernehmen kann, dann hast du immer die Möglichkeit im Hintergrund des Wrappers eine andere Mathematikbibliothek einzusetzen, ohne den Code, der darauf zugreift ändern zu müssen.

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

Naja immerhin wurde ID Software aufgrund des Patents von Create gezwungen Unterstützung für deren Soundkarten einzubauen.

Off-Topic :
Schon dumm mit den Patenten, aber beide Parteien sitzen ja in den USA, wodurch die rechtliche Situation klarer sein dürfte. Wenn die eine Partei aber in nem anderen Land sitzt, gelten ja i.d.R. die rechtlichen Bestimmungen an deren Sitz, und bei uns in Europa ist das zum Glück noch etwas anders.

On-Topic :
Ne Heidenarbeit ist das mit Sicherheit, aber da ich ja schon ne eigene Mathe-Lib habe (da ich ne wirklich 3D-Mathe an ner Schule hatte war das Teil übrigens sehr sehr interessant und lehrreich), müsste ich im Endeffekt "nur" erweitern. Aber das mit den diversen Erweiterungen ist natürlich so ne Sache (3DNow+ ist allerdings angeblich nix anderes als SSE2) und nimmt sicherlich Zeit in Anspruch, die ich momentan nicht habe. Ich werde das mal verschieben, aber auf jeden Fall zumindest ein paar Vergleichstests machen. So ne Routine um nen Vektor mit ner Matrix zu transformieren ist ja schnell geschrieben, auch wenn man mehrere Pfade proggen muss, ist dann aber ein guter Vergleichspunkt. Momentan fesselt mich Newton aber mehr

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