DirectX - Seite 3

Neuer Kommentar
 
Rorschach:

Herzlichen Dank!

Sind Ihre Berechnungen doppelt? Dann ist das Ergebnis besonders beeindruckend.

Gutes Argument. An einer Stelle war es sogar float statt double:

D = fast_length(p);

Um sie zu verdoppeln, müssen wir sie korrigieren zu 

D = length(p);

Sie können auch die letzte Zeile loswerden (analog zum XRGB-Makro), indem Sie uchar4 statt uint für das *buf-Argument verwenden. Versuchen Sie es auf diese Weise:

__kernel void Func(int N, __global double *XP, __global double *YP, __global uchar *h, __global uchar4 *buf)
{
   size_t X = get_global_id(0);
   size_t Width = get_global_size(0);
   size_t Y = get_global_id(1);
   
   float2 p;
   double D=0,S1=0,S2=0;
   
   for(int w=0;w<N;w++){ 
      p.x = XP[w]-X;
      p.y = YP[w]-Y;
      D = length(p);
      S2+=D;
      if(w<N/2)
         S1+=D;
   }   
   //
   double d=S1/S2;
   buf[Y*Width+X] = (uchar4)(0xFF,h[(int)(d*11520)],h[(int)(d*17920)],h[(int)(d*6400)]);
}
 
Serhii Shevchuk:

Das ist wirklich beeindruckend! Fps ist 1,5 mal höher als bei Shadern.

Danke, der Code funktioniert, keine Leistungseinbußen, habe nur den Alphakanal in der letzten Zeile ans Ende verschoben:

buf[Y*Width+X] = (uchar4)(h[(int)(d*11520)],h[(int)(d*17920)],h[(int)(d*6400)],0xFF);
 
Rorschach:

Das ist wirklich beeindruckend! Fps ist 1,5 mal höher als bei Shadern.

Danke, der Code funktioniert, die Leistung wird nicht beeinträchtigt, nur in der letzten Zeile wurde der Alphakanal ans Ende verschoben:

Bei dieser Implementierung ist die Leistung stark von der Anzahl der Zentren (N) abhängig. Idealerweise sollten wir die Schleife im Kernel loswerden, aber in diesem Fall müssen wir S1 und S2 zu Ganzzahlen machen. Wir werden sehen müssen, wie groß die Streuung ihrer Werte ist, und vielleicht können wir sie mit etwas multiplizieren, ohne zu viel zu sündigen. Und dann ist es möglich, die Schleife in die dritte Dimension zu übertragen, was theoretisch zu einem Leistungsgewinn bei hohen Werten von N führt.

Ich bekomme 80-90 fps auf meiner HD 7950 auf einem Full-HD-Monitor bei N=128.

 
Serhii Shevchuk:

Bei dieser Implementierung ist die Leistung stark von der Anzahl der Zentren (N) abhängig. Es wäre gut, die Schleife im Kernel loszuwerden, aber dann müssten S1 und S2 ganzzahlig sein. Wir werden sehen müssen, wie groß die Streuung ihrer Werte ist, und vielleicht können wir sie mit etwas multiplizieren, ohne zu viel zu sündigen. Und dann ist es möglich, eine Schleife in die dritte Dimension zu übertragen, was theoretisch zu einem Leistungsgewinn bei hohen Werten von N führt.

Ich bekomme 80-90 fps auf meiner HD 7950 auf einem Full-HD-Monitor bei N=128.

Meine 750ti hat 11 fps. Ich habe die technischen Daten für die Karten gefunden:

GPU
FP32 GFLOPS
FP64 GFLOPS Ratio
Radeon HD 7950 2867 717 FP64 = 1/4 FP32
GeForce GTX 750 Ti 1388 43 FP64 = 1/32 FP32

Logischerweise kann der Wechsel zu Float die fps um den Faktor 4 bei amd und 32 bei nvidia erhöhen.

 

Ich habe eine Kopie der OCL-Version erstellt. Ich bin schockiert über das Ergebnis. Bei 1600 Zentren konnte die Vidia nicht mehr als 85% geladen werden.

Die Optimierung mit vorberechneten h hat keine Auswirkung, aber es bleibt dabei. Alle Berechnungen erfolgen in Float, ich sehe keinen Sinn darin, Double zu verwenden, da alle Funktionen ohnehin Float zurückgeben.

Dateien:
pixel.zip  1 kb
Swirl2_OCL_mod.mq5  14 kb
 

Einige Schlussfolgerungen.

1) Die Vorberechnung von h hatte keine Auswirkungen.

2) Ich habe keinen Unterschied bemerkt, als ich if loswerden wollte.

S1+=D*(i<0.5 f*N);
//if(i<N*0.5 f) S1+=D;

3) Es ist langsamer,

for(int i=0;i<N;i++)
  {XP[i]= (1.f-sin(j/iArr[2*i  ].w))*wh.x*0.5 f;
   YP[i]= (1.f-cos(j/iArr[2*i+1].w))*wh.y*0.5 f;
  }
float S1=0.f,S2=0.f;
for(int i=0;i<N;i++)
  {float2 p;
   p.x=XP[i]-Pos.x;
   p.y=YP[i]-Pos.y;
   ...
  }

als es

float S1=0.f,S2=0.f;
for(int i=0;i<N;i++)
  {float2 p;
   p.x=(1.f-sin(j/iArr[2*i  ].w))*wh.x*0.5 f-Pos.x;
   p.y=(1.f-cos(j/iArr[2*i+1].w))*wh.y*0.5 f-Pos.y;
   ...
  }

Es scheint...

4) Kann die CPU nicht entlasten, d.h. Scalper Stacks etc. können vergessen werden.

 
Rorschach:

Einige Schlussfolgerungen.

1) Die Vorberechnung von h hatte keine Auswirkungen.

2) Kein Unterschied beim Loswerden, wenn

3) Es ist langsamer,

als es

Es scheint...

4) Kann die CPU nicht entlasten, d.h. Scalper Stacks etc. können vergessen werden.

In MT5 können Scalper-Stacks problemlos in einem Thread ohne OCL laufen und die CPU nicht überlasten. Das heißt natürlich nicht, dass sie nicht gebraucht wird. Nur zu Ihrer Information.

Wenn Sie beim Bau eines Pfostens die Klasse CCanvas verwenden, ist die Arbeitsbelastung proportional zur Fläche des Pfostens. Das heißt, je größer das Fenster im Mull ist, desto größer ist die Belastung, weil die gesamte Leinwand neu gezeichnet wird und nicht nur einzelne, veränderte Teile. Werden die Becherzellen jedoch in unabhängige Elemente umgewandelt, können sie unabhängig vom Rest der Leinwandfläche aktualisiert werden, wodurch sich die Zeit für das Neuzeichnen und die damit verbundene Belastung des Prozessors um ein Vielfaches verringert.

 
Реter Konow:

Auf MT5 können Scalper-Stacks problemlos in einem Thread arbeiten, ohne OCL und ohne den Prozessor zu überlasten. Das heißt natürlich nicht, dass sie nicht gebraucht wird. Nur zu Ihrer Information.

Wenn Sie beim Bau eines Pfostens die Klasse CCanvas verwenden, ist die Arbeitsbelastung proportional zur Größe des Pfostens. Das heißt, je größer das Fenster im Mull ist, desto größer ist die Belastung, da die gesamte Leinwand neu gezeichnet wird und nicht nur einzelne, veränderte Teile. Werden die Becherzellen jedoch in unabhängige Elemente umgewandelt, können sie unabhängig vom Rest der Leinwandfläche aktualisiert werden, wodurch sich die Zeit für das Neuzeichnen und die damit verbundene Belastung des Prozessors um ein Vielfaches verringert.

Der vierte fragliche Punkt. Im Remnant3D-Beispiel wird die CPU kaum belastet.

 
Rorschach:

Punkt 4 ist in Frage gestellt. Das Remnant3D-Beispiel belastet die CPU kaum.

Dies wurde bereits getestet. Die CPU auf dem MT5 wird bei normaler Dynamik des Canvas fast nicht belastet, wenn Sie einzelne Zellen, in denen sich der Wert geändert hat, neu zeichnen.

Im Gegenteil, wenn jeder eingehende Wert über die gesamte Leinwandfläche neu gezeichnet wird, wird der Prozessor stark belastet.

Der Unterschied liegt in der Anzahl der neu initialisierten Werte in der Pixelmatrix. Sie müssen einzelne Bereiche selektiv aktualisieren, und Sie werden keine Ladeprobleme haben.

 
Реter Konow:

Dies wurde bereits getestet. Die CPU auf dem MT5 wird bei normaler Dynamik des Canvas fast nicht belastet, wenn Sie einzelne Zellen, in denen sich der Wert geändert hat, neu zeichnen.

Im Gegenteil, wenn jeder eingehende Wert über die gesamte Leinwandfläche neu gezeichnet wird, wird der Prozessor stark belastet.

Der Unterschied liegt in der Anzahl der neu initialisierten Werte in der Pixelmatrix. Sie müssen einzelne Bereiche selektiv aktualisieren, und Sie werden keine Ladeprobleme haben.

Das ist das Besondere an Remnant3D: Es ist ein Vollbild-Canvas und belastet die CPU nicht.

12345678910...12
Neuer Kommentar
Grund der Beschwerde: