[CF-AL] Utiliser le GPU pour effectuer les calculs des scripts.

[TheParadox]

Bonjour.

J'ai réalisé une simulation 2D qui, en gros, fait interagir une centaine d'"atomes" entre eux.
Actuellement, je peux faire tourner la simulation avec maximum ~700 atomes pour que ça reste fluide.

Le profiler indique que mon CPU met environ 50 ms (fluctue entre 30 et 400) pour effectuer les calculs, à chaque frame, et que c'est le script de mes atomes qui consomme le plus (90%).
Bon, rien d'étonnant.

Mais j'ai remarqué que le GPU reste à 0.00 ms, et donc qu'il n'est pas utilisé, puisque aucun calcul de rendu n'est nécessaire (la simulation étant en 2D).
Du coup je me demandait si il était possible de partager les calculs entre le CPU et le GPU, pour avoir de meilleures performances.
En gros, utiliser la puissance de calcul du GPU pour simuler un second CPU.

Est-ce possible ? Et si oui, comment faire ?
Merci d'avance.

[Max]

Bonsoir,

Du coup je me demandait si il était possible de partager les calculs entre le CPU et le GPU, pour avoir de meilleures performances.
En gros, utiliser la puissance de calcul du GPU pour simuler un second CPU.

comme souvent, tout est possible. Mais je ne te cacherais pas que tu va aborder une partie plutôt avancé en terme d'algo et de code, donc j'espère que tu es bien armée sur ce point
Une piste parmi d'autres: Compute shaders

[TheParadox]

Si j'ai bien compris, il faudrait que je réécrive le script de mes atomes dans un shader, en langage DX11 HLSL ?
Ça risque d'être compliqué effectivement
Ou alors, j'écris juste la partie du code qui consomme le plus et je m'arrange pour appeler la fonction depuis le script de l'atome....
Mais est-ce que c'est possible, d'appeler une fonction d'un shader depuis un script ?

Mais du coup, ce sera le GPU qui effectuera presque tous les calculs...
Y a pas un moyen pour répartir les tâches ?
Bon après, je pourrait toujours essayer d'effectuer les calculs de la moitié des atomes avec le GPU et l'autre avec le CPU....

[Max]

Bonjour,

Oui, comme je te le laissais entendre, tu t'attaque déjà à du velu. Même si (je trouve) que c'est super intéressant.
il va falloir en effet reprendre ton approche pour une répartition des tâches entre le GPU (et ce qu'il est possible de faire avec) et le CPU. Tu as pas mal de matière sur le sujet sur le net.
Toujours avec les Compute Shaders, tu as ce genre d'article en guise d'introduction et qui permet d'en comprendre quelques bases: Unity3D Compute Shader Introduction & Tutorial

[TheParadox]

D'accord, merci, je vais y jeter un œil.

Je me demande d'ailleurs s'il n'existe pas un logiciel externe permettant d’utiliser le GPU en tant que CPU...
Je vais faire des cherches.

[ZJP]

Commence déjà par le multi-thread et éventuellement le nouveau Job System d'Unity 2018, ( ou encore) ...


https://www.youtube.com/watch?v=gibqhg0wMA0


https://www.youtube.com/watch?v=ja63QO1Imck

Si le recours au multi-cpu ne suffit pas, tu pourras alors envisager le traitement par GPU (plus compliqué).


Ps :
As tu un exemple du genre de calculs que tu veux effectuer ?

[TheParadox]

Merci ! Je vais y jeter un œil.

Les lignes du scripts qui consomment sans doute le plus sont celles-ci (appelée dans la fonction OnTriggerStay2D) :

Code : Tout sélectionner

Vector3 dir = (transform.position - collision.gameObject.transform.position) * (Mathf.Pow((transform.position - collision.gameObject.transform.position).magnitude, 2) - transform.localScale.x);
collision.gameObject.GetComponent<Rigidbody2D>().AddForce(dir * force, ForceMode2D.Force);    

Ça sert à faire s'attirer deux atomes proches, donc quand l'un est dans le trigger de l'autre.

[ZJP]

Ah, ok,... tu utilises le moteur Physique !.

Je pensais a du "pur" calcul. Dans ton cas, il faut chercher dans cette direction.

[TheParadox]

Mercii !!
En modifiant quelques paramètres (time step, max time step, et le rigibody2D des atomes en discrete), j'ai réussi à faire tourner la simulation avec 1400 atomes à 10 FPS à peu près constants, sans trop altérer les interactions physiques.
Et même 2000 à 5 FPS, mais c'est déjà pas mal.

Je vois avec tout ça qu'Unity à l'air d'être sacrément optimisé, c'est cool.

[ZJP]