schnelstmöglich dividieren?

[Memnarch]

Tag allerseits, also:

ich habe eine Formel:

Delphi-Quellcode:

Ergebnis := (A*x + B*Y + C*Z) div Wert;
Ergebnis2 := (A*x2 + B*Y2 + C*Z2) div Wert;
Ergebnis3 := (A*x3 + B*Y3 + C*Z3) div Wert;

Da diese formel ca 7 864 320 mal in der Sekunde ausgeführt wird, macht sich der unterschied der ausführungszeiten von + - * / schon ganz schön bemerkbar(1.5GHZ weil 3GHz cpu im Hyperthreading modus >.<, nein kann ich nicht ändern, arbeitsPC).

schön bemerkbar macht sich hier vor allem das DIV. Das zieht ca alleine schon 25%

Hatte mal was mit MMX angefangen, aber ich bin schlichtweg an den dokumentationen verreckt. Hatte da einen schlechten durchblick. Assembler versteh ich zwar soweit, aber MMX und CO war dann(von der dokumentation ausgesehen) dann doch zuviel. Es gab zuviele ecken und kanten für mich an dennen ich scheiterte weil ich nirgends antworten dazu fand >.<.



Hier also mal allgemein gefragt: Wie kann ich obige Kalkulation optimieren? Ergebnis muss leider Integer sein(ja ich weiß von Float nach Integer ist nicht gerade günstig, muss aber sein >.<)


MFG
Memnarch

[Phoenix]

Threaden. Du hast 2 Kerne (wg. Hyperthreading), also nutze auch beide.

[Memnarch]

Das problem war glaub ich das synchronisieren, da war dann alles wieder futsch, vllt auch was falsch gemacht mal gucken.


Genaue erklärung: 30 mal pro sekunden werden pixelbasierte operationen auf eine bitmap angewand. ich hatte es schonmal so gemacht, das je ein Thread eine hälfte des bildes machte, und am ende das ganze in eines gepackt wurde, war aber irgendwie langsamer >.<

MFG
Memnarch

[JasonDX]

Die optimale (und wahrscheinlich die einzig performant vertretbar) Lösung ist die GPU. Die ist genau für solche Sachen ausgelegt: Einfache(re) Operationen hundertfach parallel ausführen. Dein Problem sollte von den Einführungsbeispielen, die bei CUDA oder OpenCL dabei sind, gedeckt werden, d.h. der Einlese- und Implementierungsaufwand würde sich durchaus in Grenzen halten.

greetz
Mike

[Memnarch]

@Jason: das hört sich nicht schlecht an, danke . Fürchte zwar dann kann ich meinen Softwarerasterizer nicht mehr Softwarerasterizer nennen(das ist das eigentliche anwendungsgebiet ), aber trotzdem interressant . werds mir angucken.

[shmia]

Welche Werte sind denn für "Wert" zu erwarten?
Wieviele Bits sind gesetzt?
Sind nur ein oder zwei Bits gesetzt, dann könnte man mit Rechtsschieben und Addieren arbeiten.
Und dann gäbe es ja auch noch SSE3.

[himitsu]

Welche Werte haben denn die ganzen Variablen so im Durchschnitt, bzw. sind einige davor "fest"?
Eventuell kann man ja die Berechnung selber verändern

[Memnarch]

Das ganze ist wie folgt:

Obiges ist ein MinimalTeil eines Softwarerasterizers den ich geschrieben habe, nämlich die Finale kalkulation der Farbwerte eines Bildpunktes. Dazu müssen die Farbwerte der 3 Vertices interpoliert werden.

Wenn ich ein dreieck ABC habe, und einen Punkt P der dadrin liegt, muss ich die Farbwerte für P ermitteln. Nehmen wir als beispiel den rotkanal:

Alle 3 Vertices haben einen Rotwert, diese 3 Vertices haben aber an verschiedenen punkten einen stärkeren/schwächeren einfluss. Je näher P an einem Vertex ist, desto stärker ist dessen Farbanteil, ansonsten schwächer.

Kalkuliert wird so:

Ich berechne für Vertex A das Dreieck PBC, für B das Dreieck PCA, für C das dreieck PAB. Und dann noch die fläche von ABC. Wenn ich nun eine der vorherigen flächen durch die Fläche ABC teile, bekomme ich den Faktor.

Also z.B PBC/ABC = Factor von Rotwert des Vertex A.

Was ihr am anfang gelesen habt war also:

Rotwert := (FlächeA*RotA + FlächeB*RotB + FlächeC*RotC) div Gesamtfläche; Wie bereits zu sehen ist ist die kalkulierung des Faktors so rausgekürtzt dass ich pro Farbwert nur einmal dividiere.

Da gabs auch noch was mit Linearer Interpolation übers dreieck(da kann ich die Formel durch kleine additionen ersetzen), aber da bekommt man Floatwerte raus, und die muss ich erst truncaten und dann komm ich zum selben ergebnis >.<.

In dem C++ Rasterizer von dem ich gelernt habe, wurden FixedKommaZahlen verwendet, das war glaub ich um besser von Komma nach Integer zahlen zu kommen. Leider absolut keine Ahnung wie ich das in Delphi umsetzen sollte, da hatte ich ein Paar probleme v.v

MFG
Memnarch

[Jumpy]

Bei / würde das folgende gehen, wodurch AA, BB, CC nur 1 mal berechnet würden. Also nur 3 div.
Da div ja glaub ich was abschneidet funzt das so wahrsch. nicht.
Oder kannst du mit Float rechnen und nur am Ende ein Trunc drauf?

Code:

AA = A div Wert
BB = B div Wert
CC = C div Wert
Ergebnis := (AA*x + BB*Y + CC*Z);
Ergebnis2 := (AA*x2 + BB*Y2 + CC*Z2);
Ergebnis3 := (AA*x3 + BB*Y3 + CC*Z3);

[Memnarch]

ich kann mit float rechnen, aber trunc amt DIV in sachen performance gut nach.

Leider sind bei jedem durchlauf alle werte anders, ich kann mir also über mehrere durchläufe keine werte zurücklegen, das ist mein problem.