RC5-72 und der Vertex-Shader

[Sir Integral Wingate Hellsing]

Hi!

Diese Frage geht insbesondere an Zeckensack & Demirug, da das ihr Fachgebiet ist (jeder andere kann natürlich auch was dazu sagen).

Es geht um das RC5-72 Projekt (http://www.rc5team.de).
Die Clients laufen auch bei mir (siehe den RC5-72 Thread im OT-Forum) :) .

Jetzt die eigentliche Frage:

Könnte man den Code des Clients erweitern, so das GPU-Funktionen das Berechnen der Keys verbessen können, d.h. das eine DX8/9-fähige GPU durch ihren Vertex Shader zusätliche Keys pro Sekunde durchchecken kann (also nicht zur ENTlastung der CPU, sondern zur GESAMTsteigerung der Keyberechnung!) ?

Danke für eure Antworten im Voraus!

[micki]

in den pixelshadern ginge das vielleicht,
viele operationen dort sind shiften, dafür ist ne gpu nicht so gemacht (obwohl man sicherlich dividieren kann..)

Mfg
micki

[zeckensack]

Sorry, aber worum geht's da überhaupt? :)

Primzahlfaktorisierung, nehme ich mal an???
Wenn ja, kann man das eigentlich vergessen, für genaue Division und Modulo großer Zahlen reicht die Präzision einfach nicht aus.

[micki]

ist ein symmetrisches verfahren, die probieren einfach alles schlüssel durch... soweit ich weiß.

da gibt es nichts aufwendiges mit primzahlen, nur ein simples verfahren, dass mehrere male durchlaufen wird.


MfG
micki


leider unterstüzt das forum hier keine code-tags... oder?

aber hier ein source den ich so auf platte hab (ist nicht rc5-72 sonderen nur rc5-32, aber dafür einfach zu durchschauen)




/*
* Copyright distributed.net 1997-2002 - All Rights Reserved
* For use in distributed.net projects only.
* Any other distribution or use of this source violates copyright.
*
* $Id: gentests72.cpp,v 1.6 2002/09/25 15:21:30 acidblood Exp $
*/
/**************************************************************************/
/* */
/* This code is used to provide test cases for RC5-32/12/9 */
/* the RSA data security secret key challenge RC5-32/12/9 */
/* */
/* The RSA pseudo-contest solution is one of the generated codes */
/* */
/* Written by Tim Charron (tcharron@interlog.com) October 21, 1997 */
/* Modified by Décio Luiz Gazzoni Filho (acidblood@distributed.net) */
/* */
/**************************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef unsigned long int WORD; /* should be 32 bit = 4 bytes */
#define w 32 /* Word size in bits */
#define r 12 /* number of rounds */
#define b 9 /* Number of Bytes in key */
//#define c 4 /* Number of words in key */
#define c 3 /* Number of words in key -- upper(b/u), where u=bytes/word */
#define t 26 /* Size of table S=2*(r+1) words*/
WORD S[t];
WORD P=0xb7e15163, Q=0x9e3779b9; /* Magic Constants */

/* Rotation operators. x must be unsigned, to get logical right shift */
#define ROTL(x,y) (((x)<<(y&(w-1))) | ((x)>>(w-(y&(w-1)))))
#define ROTR(x,y) (((x)>>(y&(w-1))) | ((x)<<(w-(y&(w-1)))))

unsigned int Random(); // prototype

void RC5_ENCRYPT(WORD *pt, WORD *ct) /* 2 WORD input pt/output ct */
{
WORD i, A=pt[0]+S[0], B=pt[1]+S[1];
for (i=1; i<=r; i++)
{A=ROTL(A^B,B)+S[2*i];
B=ROTL(B^A,A)+S[2*i+1];
}
ct[0]=A; ct[1]=B;
}
/* end of RC5_ENCRYPT */


void RC5_DECRYPT(WORD *ct, WORD *pt) /* 2 WORD input pt/output ct */
{ WORD i, B=ct[1], A=ct[0];
for (i=r; i>0; i--)
{B=ROTR(B-S[2*i+1],A)^A;
A=ROTR(A-S[2*i],B)^B;
}
pt[1] = B-S[1]; pt[0]=A-S[0];
/* End of RC5_DECRYPT */
}

void RC5_SETUP(unsigned char *K) /* secret input key K[0...b-1] */
{ WORD i, j, k, u=w/8, A, B, L[c];
/* Initialize L, then S, then mix key into S */
for (i=b-1, L[c-1]=0; i!=-1; i--) L[i/u]=(L[i/u]<<8)+K[i];
for (S[0]=P, i=1; i<t; i++) S[i] = S[i-1]+Q;
for (A=B=i=j=k=0; k<3*t; k++, i=(i+1)%t, j=(j+1)%c) /* 3*t > 3*c */
{A=S[i]=ROTL(S[i]+(A+B),3);
B=L[j]=ROTL(L[j]+(A+B),(A+B));
}
/* End of RC5_SETUP */
}


void printword(WORD A)
{ WORD k;
for (k=0;k<w;k+=8)
printf("%02.2X", (A>>k)&0xFF);
}

void printrevword(WORD A)
{ WORD k;
printf("0x");
for (k=0;k<w;k+=8)
printf("%02.2X", (A>>(24-k))&0xFF);
}

#define TEST_CASE_COUNT 32

int main ()
{
WORD j, pt[2], ct[2]={0,0};
unsigned char key[b];
WORD bigcipher[2],bigplain[2],iv[2];
WORD seed;

if (sizeof(WORD)!=4)
printf("RC5 error: WORD has %d bytes. \n", sizeof(WORD));

seed = 982; //(WORD) times(NULL);
srand( seed ); // seed the rng so we always get the same results...

printf("// RC5-32/12/9 test cases -- generated by gentests72.cpp:\n");
printf("static const u32 rc5_72_test_cases[TEST_CASE_COUNT][TEST_CASE_DATA] = { // seed = %ld\n", seed);

for (int testcase = 0; testcase < TEST_CASE_COUNT ; testcase ++) {
if (testcase == 0) {
key[0]=0xc9;
key[1]=0x0c;
key[2]=0x03;
key[3]=0x53;
key[4]=0xc0;
key[5]=0xd4;
key[6]=0xe1;
key[7]=0xfe;
key[8]=0x85;
iv[0]=0x1f59ce07;
iv[1]=0x419a1486;
bigcipher[0]= 0x562d285a;
bigcipher[1]= 0x2fb7852a;
} else {
key[0]=Random( ) & 0x000000FF;
key[1]=Random( ) & 0x000000FF;
key[2]=Random( ) & 0x000000FF;
key[3]=Random( ) & 0x000000FF;
key[4]=Random( ) & 0x000000FF;
key[5]=Random( ) & 0x000000FF;
key[6]=Random( ) & 0x000000FF;
key[7]=Random( ) & 0x000000FF;
key[8]=Random( ) & 0x000000FF;
switch (testcase) {
case 6: key[1] = 0x00;
case 5 :key[2] = 0x00;
case 4 :key[3] = 0x00;
case 3 :key[4] = 0x00;
case 2 :key[5] = 0x00; break;
}
iv[0]=Random( ) & 0xFFFFFFFF;
iv[1]=Random( ) & 0xFFFFFFFF;
bigcipher[0]= Random( ) & 0xFFFFFFFF;
bigcipher[1]= Random( ) & 0xFFFFFFFF;
}

printf(" {"); printrevword(key[0]);
printf(","); printrevword((key[1]<<24) + (key[2]<<16) + (key[3]<<8) + key[4]);
printf(","); printrevword((key[5]<<24) + (key[6]<<16) + (key[7]<<8) + key[8]); printf(",");
printrevword(iv[0]); printf(","); printrevword(iv[1]); printf(",");

// Setup the S / L values...
RC5_SETUP(key);

// Decrypt the wordpair...
ct[0]=bigcipher[0];
ct[1]=bigcipher[1];
// decrypt (including the initial vector):
RC5_DECRYPT( ct, pt );
bigplain[0]=pt[0]^iv[0];
bigplain[1]=pt[1]^iv[1];
// Prior step's cipher becomes the xor vector for the next step (if we were doing more than 1 wordpair)...
iv[0]=ct[0];
iv[1]=ct[1];

// Print the plaintext (hex)...
printrevword(bigplain[0]);printf(",");printrevword(bigplain[1]);printf(",");
// Print the ciphertext (hex)...
printrevword(bigcipher[0]);printf(",");printrevword(bigcipher[1]);
if (testcase != (TEST_CASE_COUNT-1)) {
printf("},\n");
} else {
printf("}\n");
}
}
printf("};\n");
return 0;
}

unsigned int Random()
{
unsigned int tmp;

tmp = ( ( ( (unsigned int) rand() & 0xFF ) << 24 ) +
( ( (unsigned int) rand() & 0xFF ) << 8 ) +
( ( (unsigned int) rand() & 0xFF ) << 16 ) +
( ( (unsigned int) rand() & 0xFF ) << 0 ) );

return( tmp );
}

[zeckensack]

micki,
Schau mal,
Code-Tags!
;)

[Haarmann]

Gibts das auch in ner lesabereren Sprache? ;) Formeln oder so...

[Demirug]

Alos RC5 dürfte sich nur sehr schwer in einen Vertexshader pressen lassen. Das Verfahren baut im wesntlichen auf auf Bitrotation in Integer auf. Ein Vertexhader arbeitet mit Fliesspunktzahlen und hat keine native unterstüzung für Bitrotationen.

Zudem kommt noch hinzu das 1.1 VS noch keine schleifen können was dazu führt das man diese aufrollen muss und dann dürfte bei einer schlüsselbreite von 72 die Programmlänge nicht mehr reichen.

[micki]

deswegen hab ich ja auch pixelshader vorgeschlagen, da kann man meines wissens nach verschiedene datenformate erbitten :)

schifts könnte man simulieren durch divisionen und multiplikationen.

wenn so ne graka ne pipe von 8pixeln hat, könnte man vielleicht sehr gut pararelisieren.

am i wrong?

MfG
micki

[zeckensack]

Das sind doch keine Shifts.
Das sind Rotates :idea:

Das geht nicht (TM) :(

[micki]

manche cpus können kein rotate

da wird ma eben

a=(a>>5)|(a<<27);

gemacht um shr Eax,5 zu emulieren

oder auf der graka


rcp r2,(2^27) ; ich weiß, dass zahlen nicht direkt gehen ;)
mul r1,v0,32
mul r2,v0,r2
add ro,r1,r2

so in etwa könnte ich mir ein rotate vorstellen... vielleicht ginge sowat lustiges ja auf pixel und vertexshadern gleichzeitig :).. aber ich plädire für ps.

MfG
micki


ps. alles nur brainstorming, also sorree falls da ein fehler drinne ist.

[Sir Integral Wingate Hellsing]

Originally posted by Demirug
Alos RC5 dürfte sich nur sehr schwer in einen Vertexshader pressen lassen. Das Verfahren baut im wesntlichen auf auf Bitrotation in Integer auf. Ein Vertexhader arbeitet mit Fliesspunktzahlen und hat keine native unterstüzung für Bitrotationen.

Zudem kommt noch hinzu das 1.1 VS noch keine schleifen können was dazu führt das man diese aufrollen muss und dann dürfte bei einer schlüsselbreite von 72 die Programmlänge nicht mehr reichen.

Hm, ihr seid die Fachmänner! ;)

Aber würde es z.B. mit dem VS 1.3/1.4/2.0 gehen?

Es ist einfach nur wichtig überhaupt ein Performanceplus zu bekommen, koste es was es wolle!

Bitte checkt das mal durch, denn JEDER Key der Extra pro Sekunde durchgetestet werden kann zählt!

P.S.: Natürlich geht man dabei von aus, das die GPU dann nur damit beschäftigt ist und nicht nebenbei noch etwas rendern oderso machen muss...

@Micki: Mit dem PS? Erklär mal bitte!

EDIT:

Source-Code und Infos gibt es hier (http://www.distributed.net//rc5/index.php.de) !

[micki]

PS = pixelshader

da wird eh mit int werten gerechnet (naja, zimindestens fixpoint normalerweise) könnte man im multipass verfahren vielleicht sehr parallelisiert arbeiten, müßte man eigentlich auch... ich weiß net ob, ob das nun so schlau wäre

in den vertexshadern könnte man vielleicht auch was anstellen, wenn man hofft, dass die vertexshader piplines genug präzision beim rechnen mitbringen

hmm.. das wäre ein sehr aufwändiges projekt.. sowas..

MfG
micki

ps. wozu ist dir das so wichtig? dauert eh jahre bis die was rausbekommen.. wenn überhaupt.

[Demirug]

so ich habe mal überschlagen

180 Passes @ 1000000 Keys auf einer 128 MB Karte. Mindestens PS 2.0 aber da habe ich noch bedenken wegen dem Instruktioncount.

Das prüfen ob der Code gefunden wurde müsste aber möglicherweise die CPU machen. da bin ich mir noch nicht ganz sicher.

Das primäre füllen des RAMs mit den Keys müsste wohl auch die CPU mache aber da läst sich mögclicherweise auch noch ein PS zusammenzimmern.

[Sir Integral Wingate Hellsing]

Originally posted by Demirug
so ich habe mal überschlagen

180 Passes @ 1000000 Keys auf einer 128 MB Karte. Mindestens PS 2.0 aber da habe ich noch bedenken wegen dem Instruktioncount.

Das prüfen ob der Code gefunden wurde müsste aber möglicherweise die CPU machen. da bin ich mir noch nicht ganz sicher.

Das primäre füllen des RAMs mit den Keys müsste wohl auch die CPU mache aber da läst sich mögclicherweise auch noch ein PS zusammenzimmern.

GOTT!

Ich hoffe du checkst das genau aus?
Vllt freun die sich ja vom distributed.net Team über ne nette Idee von dir ;)

P.S.: 1 Mio Keys/s ? :O

[Demirug]

Originally posted by Sir Integral Wingate Hellsing


GOTT!

Ich hoffe du checkst das genau aus?
Vllt freun die sich ja vom distributed.net Team über ne nette Idee von dir ;)

P.S.: 1 Mio Keys/s ? :O

Eigentlich hätte ich ja besseres zu tun aber die Sache hat den gewissen "crazy factor" ;)

Wie viele Keys hängt von der Grafikkarte ab. Die 1 Mio bezog sich nur darauf das diese sozusagen auf einen Schlag geprüft werden. Es hängt also davon ab wie lange die Karte für die 180 Passes@1 Mio "Pixel" braucht.

@zeckensack: Liest du noch mit? Ich brauche jemanden der meine Ideen validiert.

[Sir Integral Wingate Hellsing]

Originally posted by Demirug


Eigentlich hätte ich ja besseres zu tun aber die Sache hat den gewissen "crazy factor" ;)

Wie viele Keys hängt von der Grafikkarte ab. Die 1 Mio bezog sich nur darauf das diese sozusagen auf einen Schlag geprüft werden. Es hängt also davon ab wie lange die Karte für die 180 Passes@1 Mio "Pixel" braucht.

@zeckensack: Liest du noch mit? Ich brauche jemanden der meine Ideen validiert.

Hoffentlich hat Zecki Zeit!

Das wärs doch! ;)

Wir haben ja schon nen RC5-72 3DC-Team... aber wenn ausm 3DC noch ne Innovation für das Proggy kommt...

:D

[Demirug]

Ergebnisse des ersten Durchdenkens:

Ich habe mir den Referenzcode für RC5-72 besorgt:


#define P 0xB7E15163
#define Q 0x9E3779B9

#ifdef __cplusplus
extern "C" s32 rc5_72_unit_func_ansi_ref ( RC5_72UnitWork *, u32 *, void * );
#endif

s32 rc5_72_unit_func_ansi_ref (RC5_72UnitWork *rc5_72unitwork, u32 *iterations, void * /*memblk*/)
{
u32 i, j, k;
u32 A, B;
u32 S[26];
u32 L[3];
u32 kiter = *iterations;
while (kiter--)
{
L[2] = rc5_72unitwork->L0.hi;
L[1] = rc5_72unitwork->L0.mid;
L[0] = rc5_72unitwork->L0.lo;
for (S[0] = P, i = 1; i < 26; i++)
S[i] = S[i-1] + Q;

for (A = B = i = j = k = 0;
k < 3*26; k++, i = (i + 1) % 26, j = (j + 1) % 3)
{
A = S[i] = ROTL3(S[i]+(A+B));
B = L[j] = ROTL(L[j]+(A+B),(A+B));
}
A = rc5_72unitwork->plain.lo + S[0];
B = rc5_72unitwork->plain.hi + S[1];
for (i=1; i<=12; i++)
{
A = ROTL(A^B,B)+S[2*i];
B = ROTL(B^A,A)+S[2*i+1];
}
if (A == rc5_72unitwork->cypher.lo)
{
++rc5_72unitwork->check.count;
rc5_72unitwork->check.hi = rc5_72unitwork->L0.hi;
rc5_72unitwork->check.mid = rc5_72unitwork->L0.mid;
rc5_72unitwork->check.lo = rc5_72unitwork->L0.lo;
if (B == rc5_72unitwork->cypher.hi)
{
*iterations -= (kiter + 1);
return RESULT_FOUND;
}
}

#define key rc5_72unitwork->L0
key.hi = (key.hi + 0x01) & 0x000000FF;
if (!key.hi)
{
key.mid = key.mid + 0x01000000;
if (!(key.mid & 0xFF000000u))
{
key.mid = (key.mid + 0x00010000) & 0x00FFFFFF;
if (!(key.mid & 0x00FF0000))
{
key.mid = (key.mid + 0x00000100) & 0x0000FFFF;
if (!(key.mid & 0x0000FF00))
{
key.mid = (key.mid + 0x00000001) & 0x000000FF;
if (!key.mid)
{
key.lo = key.lo + 0x01000000;
if (!(key.lo & 0xFF000000u))
{
key.lo = (key.lo + 0x00010000) & 0x00FFFFFF;
if (!(key.lo & 0x00FF0000))
{
key.lo = (key.lo + 0x00000100) & 0x0000FFFF;
if (!(key.lo & 0x0000FF00))
{
key.lo = (key.lo + 0x00000001) & 0x000000FF;
}
}
}
}
}
}
}
}
#undef key
}
return RESULT_NOTHING;
}


Die inneren Schleifenanweisungen habe ich mal fett makiert da diese ja die eigentliche Arbeit machen.

In Summe haben wir es mit diesen 5 Anweisungsfolge zu tun:


1. S[i] = S[i-1] + Q;
2. A = S[i] = ROTL3(S[i]+(A+B));
3. B = L[j] = ROTL(L[j]+(A+B),(A+B));
4. A = ROTL(A^B,B)+S[2*i];
5. B = ROTL(B^A,A)+S[2*i+1];


Die erste Anweisung macht nichts anderes als ein Feld mit Konstanten zu füllen. Das dürfte kein Problem sein.

In den Folgen 2-5 sind 3 primäre Operationen zu erkennen:

1. Xor
2. Rotate Left
3. Addition


Dummerweise alles als 32 Bit Integer Rechnung. Wir haben aber keine 32 Bit Integer in den Pixelshader.

Lösungsansatz: Jeder 32 Bit Integer wert kann in einen 4*8 Bit Wert aufgeteilt werden. Jede der 3 benötigten Operationen kann durch Texturesampling und einfache 8 Bit Rchenoperationen ersetzt werden.

1. Xor: Ein Exclusive Oder wird von den Pixelshader nicht unterstützt. Aus diesem Grund verwendet man eine 256*256 Pixel Texture welche eine Xor Tabelle für alle möglichen Kombinationen mit 8-Bit Werte enthält. Aus den zwei (A und B) 32 Bit Grundwerten erzeugt man nun 4 Texturekoordinaten. (A.R|B.R) (A.G|B.G) (A.B|B.B) (A.A|B.A) und sampeln damit aus unserer XOr Tabelle. Aus den 4 8 Bit Werte setzt man dann wieder einen 32 Bit RGBA Wert zusammen.

2. Rotate Left: Auch diese Operation läst sich nicht direkt ausführen. Da wir eine Rotation in einem 32 Bit Register ausführen sollen führen Rotationswerte >= 32 ja dazu das wir einen mehrfachen umlauf hätten. Also brauchen wir nur den Divisonrest einer Divison durch 32. Pixelshader können keine Divison. Der Divsionsrest aus 32 läst sich aber glücklicherweise durch eine Bitmaskierung ermitteln. Auch hier könnte man eine Texture (256*1) als Tabelle benutzten welches aus den letzten 8 Bit (A) den Divisionsrest ermittelt.

Da unser Ausgangswert in der Form 4*8 vorliegt sollte man in auch in dieser Form verarbeiten. Für jedes der 4 Bytes speichern wir eine Tabele 256*32 welche für jede mögliche Kombination das ergebniss als 32 bit Wert enthält. Nun haben wir 4 32 Bit Werte (RGBA) die vorodert werden müssen.

Hier können wir wiederrum auf eine 256*256 Texture zurückgreifen. Dummerweise müssen wir um die 4 Werte zu verrechnen 12 mal sampeln. Da die 4 Werte aber besondere Bedinguen erfülen (es kann die kombination 1-1 nicht geben) läst sich hier möglicherweise noch eine bessere Lösung finden.

3. Addition: Auch hier kommen wir nicht umhin die 32 Bit Addtion in 4 8 Bit Additionen zu zerlegen. Die Idee hierzu ist eine Texture welche als Rot Anteil das Ergebniss zurückliefert und im Grün Anteil das überlaufbit enthält. Damit wir mit dem überlaufbit auch was anfangen können müssten wir eine 3d Texture benutzten 256*256*2 Die erste schicht enthält die Additionergebnisse für berechnungen ohne gesetzte überlaufbit die zweite schicht wäre dann für Berechnungen mit gesetzten überlaufbit.

Alle 3 benötigten Operationen sind also mit einer 4*8 Bit Pixelshader ALU durchführbar. Untersuchungen bezüglich dem Instrucktionscount und dem dependent Level müssen noch erfolgen. Die Verfahren lassen allerdings an vielen Stellen ein zwischenspeichern zu so das es auch möglich sein sollte das ganze Verfahren auf einer PS 1.1 fähigen Karten durchzuführen allerdings mit einer wirklich grossen Anzahl von Passes.

Die Anzahl der in einem durchgang berechenbaren Keys ergibt sich aus der verbleibenden Speichermenge nachdem alle benötigten tabellen in die Karte geladen sind. Dieser Ram muss auf 32 gleichgrosse Texturen (für A, B, S[26] und L[3] und eine Temporäre) aufgeteilt werden. Diese werden dann wechselweise als Texturen oder rendertargets benutzt

So es wäre nett wenn jemand das ganze auf logische Fehler untersuchen könnte ;)

[Birdman]

hrhr, ich seh schon....die schönen neuen Graka-Verpackungen kriegen ein neues Featureset

- 256MB DDR Hispeed ram, für noch mehr Crunch-Power(TM)

[Demirug]

Originally posted by Birdman
hrhr, ich seh schon....die schönen neuen Graka-Verpackungen kriegen ein neues Featureset

- 256MB DDR Hispeed ram, für noch mehr Crunch-Power(TM)

Die Pixelshaderleistung dürfte dabei doch noch etwas wichtiger sein als die RAM menge

[zeckensack]

Guten Morgen :wink:

Japp, liest sich gut.

[Demirug]

Update:

Für das verordern habe ich eine schnellere Lösung gefunden. Einfach addieren. Von der reinen Logik her ist das in diesem Speziellen Fall auch korrekt.

Für die primären Operationen habe ich mal schnell ein paar Shader erzeugt (ich liebe Cg). Mit dem R300 wird das im ersten Anlauf erst mal nichts. Mir reicht das Dependent Read Limit dort nicht aus. Eine erste Version wird also erst mal NV3x only sein. Sorry aber mir geht es erst mal darum ob es überhaupt möglich ist. Später kann man dann über Versionen für PS 2.0/1.4/1.1 nachdenken.

In erster Annährung wird aber erst einmal ein Testprogramm notwendig sein welches überprüft ob eine PS-ALU die benötigen Operationen korrekt ausführen kann.

Da ich primär aber auch noch andere Dinge erldeigen muss kann das aber alles ein bischen länger dauern.

[Sir Integral Wingate Hellsing]

Originally posted by Demirug
Update:

Für das verordern habe ich eine schnellere Lösung gefunden. Einfach addieren. Von der reinen Logik her ist das in diesem Speziellen Fall auch korrekt.

Für die primären Operationen habe ich mal schnell ein paar Shader erzeugt (ich liebe Cg). Mit dem R300 wird das im ersten Anlauf erst mal nichts. Mir reicht das Dependent Read Limit dort nicht aus. Eine erste Version wird also erst mal NV3x only sein. Sorry aber mir geht es erst mal darum ob es überhaupt möglich ist. Später kann man dann über Versionen für PS 2.0/1.4/1.1 nachdenken.

In erster Annährung wird aber erst einmal ein Testprogramm notwendig sein welches überprüft ob eine PS-ALU die benötigen Operationen korrekt ausführen kann.

Da ich primär aber auch noch andere Dinge erldeigen muss kann das aber alles ein bischen länger dauern.

super!

Hauptsache es gibt erstmal einen Grundansatz (egal ob nV oder ATi)!
Darauf können wir (bzw ihr ich hab ja nur die Idee gehabt) dann aufbauen :)

[Neo69]

mein respekt geht an demirug - ziemlich cool, dass du neben deinen ganzen anderen dingen noch lust hast, hier deine ideen zu sammeln und dran zu arbeiten, ich hab sogar ein bißchen davon verstehen können *g*

[Sir Integral Wingate Hellsing]

*push*

Gibts was neues?