Moin,

ich hab einen kleinen performance engpass mit meiner athlon64 cpu.
diese ist leider nur in der lage 6mb/sek mit einen aes256 zu verschlüsseln.

nun hab ich mir noch überlegt was schnell viele datenmengen kopieren und transformieren kann.
ergebnis:
eine grafikkarte

da ich noch nie etwas mit grafik programmiert habe und auch nicht die leistungsfähigkeit des pixelshaders kenne - meine frage an euch profis.

ist es möglich in einen pixelshader einen aes abzubilden?

für die die den aes nicht kennen - dieser macht einfache binäroperationen wie z.b. and/or/xor und bit shiften auf datenblöcke.

jo ich weiss die idee ist freakig, aber vor 10 jahren hab ich auch in postscript ein madelbrot geschrieben welches in drucker gerendert wurde.
(500 byte programm -> 4 stunden druckzeit auf einen dec/hp laserdrucker)

Also mit einem Grafikkarte kannst du keine Bitoperationen durchführen. Wäre mir zu mindest neu. Die ist nur in der Lage normale mathematische Operationen für Vektoren etc. durchzuführen. Evtl. gäbe es noch ein paar freakige Tricks in denen man Bilder verwendet aber ich denke mal nicht, dass es sonderlich Praxistauglich wäre. Der Befehlspeicher für die Grafukkarte ist leider recht beschränkt und man gerät ziemlich schnell an die Grenzen von dem was Sie zu Leisten im stande ist.

Ich denke mal es wäre sinnvoller deinen Algorithmus zu optimieren anstelle zu versuchen den Algorithmus auf irgendetwas anderem zu tricksen. Denn 6mb/s für Bitoperationen finde ich recht wenig wenn ich ehrlich bin. Ich habe ne CPU Funktionsschnittstelle in meinem Texturen Loader eingebaut und der kann in wenig Zeit komplexe Funktionen auf Bilder anwenden, die ein knappes MB Speicher verschlingen.

Achja. Bin nicht der Wahnsinnguru was Shader angehen. Kenne also nicht alle Möglichkeiten was damit machbar ist.

Nun, sofern die Karte bedingte Anweisungen kann, muss sie zumindest OR, AND und NOT können. Da aber (A XOR B) äquivalent zu (NOT A AND B) OR (A AND NOT B) ist, haben wir uns auch den XOR gebastelt. Bitshifts lassen sich im übrigen prima mit Multiplikationen oder Divisionen durch Potenzen von 2 simulieren. Wenn wir also an die Ergebnisse der OR, AND und NOT Operationen kommen und diese nicht in irgendwo in der GPU verschwinden, dann haben wir eigentlich alles nötige - aber meine fähigkeiten in Sachen Shader sind quasi nicht vorhanden - ich weis also nix Ob das aber einen merklichen Geschwindigkeitsvorteil liefert, wenn die Hardware nicht von sich aus XOR kann, mag ich bezweifeln. Und 6Mb halte ich doch für ein bischen wenig auf Maschienen mit mehreren GHz, mind. 6GByte/s Transfer zum Speicher und mind. 1/2 Mb Cache und 64 Bit registern (aber auch 32 muss genug sein).

die ct/ix (weiss nicht mehr welche von beiden) hatte ähnliche geschwindigkeitswerte.
eine c3 cpu entlasste da halt aufgrund ihrer padlock einheit.
aber ich hab nunmal ein athlon64 und zwei gf6600 und halt keine c3. (welche ich auch nicht möchte )

daher nur diese krank idee.

Außerdem sind Shader nicht sooooo schnell wie die Karten eigentlich sind. Die Programmierbaren Einheiten sind etwas lamer...

Aber eventuell kannst du ja deine Daten als Farben Codieren und mittels Blendoperationen oder mittels Register Combiner was machen... Wobei die net auf Bits arbeiten, sondern mit normaler Mathematik. Über den Ansatz kannst du auf alle Fälle die volle Hardwareunterstützung abfassen.

PS: Nette Idee, der Hardwaremissbrauch

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hier www.gpgpu.org/ gibt es zu dem Thema noch weitere Infos. Ich kenne den Algorithmus jetzt nicht, aber alles was sich gut paralellisieren läßt, kann man über Shader berechnen. Allerdings ist zu bedenken, dass so ein Shader für jeden Pixel unabhängig ausgeführt wird. Man kann also nicht direkt z.B auf die Nachbarwerte zugreifen. AND kann man durch Multiplikation, OR durch Maximumsbildung und NOT durch 1-x nachbilden.

hey danke lars, der link ist cool.

mal schau'n ob ich da was finde.

d.h. also das wenn ich z.b. auf eine 2d texture ein wellen muster will dann muss der shader jeden pixel einzeln betrachten und transformieren?

Der Shader wird für jeden Pixel, der gezeichnet wird, aufgerufen und gibt dann jeweils einen Farbwert (oder bis zu vier mit Extension) aus, aber er kann nicht festlegen auf welche Position der Wert geschrieben wird, denn die bekommt er als Parameter vorgegeben. Alle Berechnungen für die Pixel sind voneinander unabhängig und man kann erst auf die Ergebnisse zugreifen, wenn der Shader auf alle Pixel angewendet wurde. Das kann unter Umständen eine gewisse Einschränkung sein. Daher verwenden die meisten Verfahren mehrere Schritte. Innerhalb des Programms gibt es nur wenige Einschränkungen man kann sogar while schleifen benutzen und hat bis zu 65535 Befehle.

Für numerische Verfahren eignet sich das wohl ganz gut. Habe gelesen, dass man damit große Systeme von Differentialgleichungen lösen kann u.ä. Irgendwann wird es auch richtige integer mit boolschen Verknüpfungen geben, aber im Moment weiß ich nicht ob es sinnvoll ist float Zahlen zur Bit-Kodierung zu benutzen.

das heisst verzerrungen z.b. wie von einer lupe sind nicht mit einen pixelshader zu machen?

IMHO spricht nichts dagegen, dass im Pixelshader Verzerrungen berechnet werden können. Wo denn auch sonst?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Verzerrungen sind kein Problem. Man kann ja frei von beliebigen Positionen aus Texturen lesen.

meine unwissenheit von shadern ist gross.

wenn aber ein shader von beliebigen positionen in einer texture lesen kann, wo wird das ergebnis ausgegeben?
resultiert da nicht eine neue texture raus oder wird das ergebnis direkt in den viewport gemalt?

Wenn du auf OpenGL Flächen einen Shader anwendest, dann wird dieser für jedes zu zeichnende Pixel aufgerufen. Je nachdem was du vor hast kannst du das entweder direkt auf den Bildschirm zeichnen oder eben in eine Textur die du dann wiederum auf den Bildschirm bringen kannst. Für deinen Fall würde ich evtl mit einem PBuffer (nicht sichtbarer Speicherbereich ähnlich einem normalem Viewport) arbeiten. Und dann das ganze im Orthomodus (also 2D) berechnen. Somit hast du keine Tiefe sondern nur einen flachen Bereich.
Zum Weiteren Verständniss solltest du dir evtl mal das glsl2 Tutorial anschauen

2D Tutorial
PixelBuffer Tutorial

für jeden pixel der gezeichnet wird (im regelfall dann in den framebuffer oder pixelBuffer) wird der pixelshader einmal aufgerufen, der output von dem pixel befindet sich dann an der position des pixels (auch wenn tiefenwerte veränderbar sind), man kann halt nur zB die texturkoordinaten verändern um verzerrungseffekte zu erzeugen

ich weiss ja nicht wie du den aes implementiert hast, aber an deiner stelle würd ich versuchen aus der CPU alles herauszuholen. Stichworte: Assembler, MMX, SSE2 da du ja mit ganzzahlen rechnest. Ich hab mich noch nicht mit den Extensions für ganzzahlen beschäftigt sondern nur mit Gleitkommazahlen, aber FPU-Assembler in reinform ist 2x so schnell wie der standard von delphi, sobald viele auf mehreren werten "paralell" ausfürbare sachen kommen dann legen die Extenstions nochmal vor. Paralell heis auch nicht dass es nur ein starres muster giebt mit shulffeln kann man einiges machen.

Musst dir mal anschauen