DirectX - page 3

Nouveau commentaire
 
Rorschach:

Merci beaucoup !

Vos calculs sont-ils en double ? Le résultat est alors particulièrement impressionnant.

Bon point. En effet, à un endroit, c'était float au lieu de double:

D = fast_length(p);

Pour le rendre double, nous devons le corriger en 

D = length(p);

Vous pouvez également vous débarrasser de la dernière ligne (analogue à la macro XRGB) en appliquant uchar4 au lieu de uint pour l'argument *buf. Essayez comme ça :

__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:

C'est vraiment impressionnant ! La vitesse est 1,5 fois plus élevée qu'avec les shaders.

Merci, le code fonctionne, pas de dégradation des performances, j'ai juste déplacé le canal alpha à la fin dans la dernière ligne :

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

C'est vraiment impressionnant ! Le nombre de Fps est 1,5 fois plus élevé qu'avec les shaders.

Merci, le code fonctionne, les performances ne sont pas dégradées, seulement dans la dernière ligne le canal alpha a été déplacé à la fin :

Dans cette mise en œuvre, la performance dépend fortement du nombre de centres (N). Idéalement, nous devrions nous débarrasser de la boucle dans le noyau, mais dans ce cas, nous devrons rendre S1 et S2 entiers. Nous devrons voir quelle est l'ampleur de la diffusion de leurs valeurs et peut-être pourrons-nous les multiplier par quelque chose sans trop pécher. Et ensuite, il est possible de transférer la boucle à la troisième dimension, ce qui théoriquement donnera un gain de performance à des valeurs élevées de N.

J'obtiens 80-90 fps sur ma HD 7950 sur un moniteur full-hd à N=128.

 
Serhii Shevchuk:

Dans cette mise en œuvre, les performances dépendent fortement du nombre de centres (N). Il serait bon de se débarrasser de la boucle dans le noyau, mais alors S1 et S2 devraient être des entiers. Nous devrons voir quelle est l'ampleur de la diffusion de leurs valeurs et peut-être pourrons-nous les multiplier par quelque chose sans trop pécher. Et il est alors possible de transférer une boucle en troisième dimension, ce qui théoriquement donnera un gain de performance à des valeurs élevées de N.

J'obtiens 80-90 fps sur ma HD 7950 sur un moniteur full-hd à N=128.

Ma 750ti a 11 fps. J'ai trouvé les spécifications des cartes :

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

Logiquement, passer en mode flottant peut augmenter les fps par un facteur de 4 sur amd et de 32 sur nvidia.

 

Fait une copie de la version OCL. Je suis choqué par le résultat. A 1600 centres, on ne pouvait pas charger la vidéoad à plus de 85%.

L'optimisation avec le h précalculé n'a aucun effet, mais on le laisse. Tous les calculs sont en float, je ne vois pas l'intérêt d'utiliser le double puisque toutes les fonctions renvoient du float de toute façon.

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

Quelques conclusions.

1) Le précalcul de h n'a eu aucun effet.

2) Je n'ai pas remarqué de différence en me débarrassant de si

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

3) Il est plus lent,

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;
   ...
  }

qu'elle

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;
   ...
  }

il semble...

4) On ne peut pas décharger le CPU, c'est-à-dire que les piles de scalpeurs, etc. peuvent être oubliées.

 
Rorschach:

Quelques conclusions.

1) Le précalcul de h n'a eu aucun effet.

2) Aucune différence pour se débarrasser de si

3) Il est plus lent,

qu'elle

il semble...

4) On ne peut pas décharger le CPU, c 'est-à-dire que les piles de scalpeurs, etc. peuvent être oubliées.

Dans MT5, les piles de scalpeurs peuvent facilement fonctionner dans un seul thread sans OCL et ne pas surcharger le CPU. Bien sûr, cela ne signifie pas qu'elle n'est pas nécessaire. Juste un FYI.

Si vous utilisez la classe CCanvas pour construire un meneau, la charge de travail sera proportionnelle à la surface du meneau. En d'autres termes, plus la fenêtre est grande, plus la charge est lourde, car c'est l'ensemble de la toile qui est redessinée, et non les différentes parties modifiées. Cependant, en transformant les cellules des gobelets en éléments indépendants, elles peuvent être mises à jour indépendamment du reste de la zone du kanvas, ce qui réduit de plusieurs fois le temps de redécoupage et la charge qu'il impose au processeur.

 
Реter Konow:

Sur MT5, les piles de scalpeurs peuvent facilement fonctionner dans un seul thread, sans OCL et sans surcharger le processeur. Bien sûr, cela ne veut pas dire qu'il n'est pas nécessaire. Juste un FYI.

Si vous utilisez la classe CCanvas pour construire un meneau, la charge de travail sera proportionnelle à la surface du meneau. En d'autres termes, plus la fenêtre est grande, plus la charge est lourde, car c'est l'ensemble de la toile qui est redessinée, et non les parties individuelles modifiées. Cependant, en transformant les cellules des gobelets en éléments indépendants, elles peuvent être mises à jour indépendamment du reste de la zone du kanvas, ce qui réduit de plusieurs fois le temps de redécoupage et la charge qu'il impose au processeur.

4ème point en question. Dans l'exemple de Remnant3D, le processeur est à peine sollicité.

 
Rorschach:

Le point 4 est en question. L'exemple de Remnant3D sollicite à peine le processeur.

Ceci a été testé. Le CPU du MT5, en cas de dynamique normale du canevas, n'est presque pas chargé, si vous redessinez les cellules individuelles dans lesquelles la valeur a changé.

Au contraire, si chaque valeur entrante est redessinée sur toute la surface du canevas, le processeur sera beaucoup plus sollicité.

La différence réside dans le nombre de valeurs réinitialisées dans le tableau de pixels. Vous devez mettre à jour les zones individuelles de manière sélective et vous n'aurez pas de problèmes de charge.

 
Реter Konow:

Ceci a été testé. Le CPU sur MT5, en cas de dynamique normale du canevas, n'est presque pas chargé, si vous redessinez les cellules individuelles dans lesquelles la valeur a changé.

Au contraire, si chaque valeur entrante est redessinée sur toute la surface du canevas, le processeur sera beaucoup plus sollicité.

La différence réside dans le nombre de valeurs réinitialisées dans le tableau de pixels. Vous devez mettre à jour les zones individuelles de manière sélective et vous n'aurez pas de problèmes de charge.

C'est l'avantage de Remnant3D : il s'agit d'un canevas plein écran qui ne charge pas le processeur.

12345678910...12
Nouveau commentaire