Discussion :

[LaurentDur]

Salut! Tout d'abord je tiens à préciser que je ne savais pas très bien ou poster ce sujet.

Je voudrais lancer un programme que j'ai compilé avec mon propre compilateur pour le GPU.

Mais je ne sais pas de trop comment m'y prendre et apparemment ça ne fonctionne pas comme je le pense.

-Je pensais qu'il fallait écrire à un endroit précis dans la VRAM, envoyer l'id tu thread avec une instruction marche/arrêt et puis l'adresse de la fonction qui doit être appelée par le thread. Mais ça n'a pas l'air d'être commce ça d'après le code source de mesa 3D trouvé ici :

https://github.com/mesa3d/mesa

Apparemment il utilise les threads de c11 pour lancer des threads au niveau du GPU, pourtant g++ et gcc ne peuvent pas générer de code binaire pour des GPU.

Alors je ne sais pas très bien comment dois je m'y prendre.

Merci.

[Bousk]

Je suis pas expert en 3D ou GPU mais il me semble qu'il se contrôle uniquement via des commandes, que OpenGL ou DirectX poussent.
Donc les threads GPU, c'est pas ton problème. Tu utilises les API Direct3D ou OpenGL qui permettent de le manipuler et faire le rendu.
Et un programme GPU c'est un Shader. Avec OpenGL ce sont les combos glCreateShader/glCompileShader.
Si tu le compiles toi-même (pourquoi donc faire ça ? Comment ? C'est quoi ta sortie ?), tu réalises ces étapes mais il reste les étapes suivantes pour l'envoyer sur la carte graphique et là ça dépasse mes connaissances. Et ça dépend peut-être du modèle de carte graphique.
Je ne vois absolument aucune raison de ne pas simplement écrire du glsl et utiliser OpenGL ?

[Garvelienn]

Bonjour,

Je complète la réponse précédente.
Vous pouvez également utiliser OpenCL ou CUDA si vous avez une carte Nvidia. Ces deux API sont faites pour du calcul brut (traitement d'image, machine learning, etc) contrairement à OpenGL et DirectX qui sont plus pour du rendu graphique (bien qu'on puisse les utiliser pour autre chose). Dans la même philosophie que ces deux dernières, vous avez Vulkan qui permet d'avoir plus de contrôle sur ce qui est fait au niveau du GPU (allocation mémoire, etc).
Je ne connais pas d'autres moyens de travailler sur le GPU. Si vous trouvez, cela m’intéresse, svp

[LaurentDur]

D'après les spécifications techniques de ma carte graphique, il faut coder un kernel pour envoyer des commandes dans un registre pour demander au GPU de charger des données depuis la RAM et dans un autre registre pour les traiter, mais c'est le GPU qui gère lui même les threads au niveau du hardware, on ne peut pas les contrôler.
Mesa 3D passe par une lib (libdrm) pour faire cela mais je ne sais pas quel code taper pour faire ça car il n'y a que les spécifications techniques et le code open source de mesa est trop dense, surtout pour quelqu'un comme moi qui n'a jamais fait ça.

Normalement, tout le monde passe par OpenGL pour du rendu ou bien OpenCL/Cuda pour du calcul, cependant, je ne comprend pas très bien ce qui se passe derrière de ce fait, je n'arrive pas à les utiliser.

Donc je voudrais faire ça pour mieux comprendre comment opengl fonctionne et surtout, les fonctionnalités d'opengl 4.5, que je n'arrive absolument pas à maîtriser, surtout au niveau de la synchronisation des données avec les images et en plus de ça, le rendu est trop lent.
J'ai déjà recoder quelques libs/moteurs de rendu pour essayer de comprendre comment cela fonctionne parce que je n'arrivais pas à réutiliser l'existant (chose qui pose vraiment problème chez moi), et ça a plutôt bien porté ses fruits, mais, pour un driver graphique, ça à l'air d'être une tout autre histoire, et puis, je manque cruellement d'infos.

J'ai essayé plusieurs techniques pour éviter de devoir utiliser des images :

-Utiliser de très grandes textures et faire un tri, mais, les grandes textures font ramer le logiciel de traitement d'images.
-Utiliser des bindless textures mais, mon GPU ne supporte pas GL_ARB_bindless_texture dans le fragment shader.
-Utiliser des per pixels linked list mais je n'arrive pas à les utiliser correctement, l'affichage n'est pas synchronisé, et en plus, ce n'est pas performant.
-Utiliser du weighted blending OIT mais là encore ça ne fonctionne pas.

Sinon j'ai déjà pensé à d'autres solutions comme :

-Diviser la carte en plusieurs zones et n'utiliser que les même images par zone.
-Faire une couche de rendu pour le sol, une autre pour les modèles et une autre pour les sorts.

Cependant, comme j'ai le temps, et que je n'ai rien de spécial à faire (je ne peux plus avancer sur mon projet car je n'ai pas d'équipe pour le graphisme et tout ça), je me suis un peu penché sur l'écriture d'un compilateur GLSL et d'un driver pour renforcer mes connaissances au niveau programmation, mais aussi, pour mieux comprendre comment le hardware fonctionne.

Mais si je manque d'informations je vais devoir laisser tomber.
Le plus crucial ça va être de savoir comment charger des données dans la VRAM et les traiter, une fois que je saurai comment faire ça, le reste, ça ne devrait pas être trop compliqué.
Avec libdrm on peut le faire mais tout ce que j'ai trouvé c'est un code qui charge des données dans la VRAM mais pas des instructions, ni des commandes.

[Bousk]

Ha le retour de Laurent...
"je ne sais pas utiliser OpenGl 4.5" => "mon rendu est trop lent" => "je vais recoder le drivers graphique". Parce que c'est tout à fait la chose à faire bien sûr
Ce ne sont pas les sources, tutos et exemples qui manquent sur internet il me semble. Et le nombre de personnes qui l'utilisent, amateurs et pros, sont la preuve que ça fonctionne.
Y'en a même pas mal dispos ici-même https://jeux.developpez.com/tutoriels/OpenGL-ogldev/ pour OpenGL 3+.
Ton problème est toujours de l'ordre de l'interface homme-machine. Ne pas savoir utiliser une brouette ne se résoud pas en changeant la roue pour un carré en bois bricolé dans son garage.

[LaurentDur]

Je m'attendais à ce genre de réponse. Déjà je ne vois pas de tutoriels sur opengl 4.5 et les per pixels linked list.
Et sans les per pixels linked lists mon rendu fonctionne bien et tout ce qui est écrit dans ce tutoriel je l'ai déjà implémenter.
C'est dans la manie des gens de toujours rejeter la faute sur les autres ?
Bien sûr que j'ai déjà été voir sur Internet.
Ça me fait penser au développeur de la SFML qui a supprimé mon compte parce que j'ai dit que sa librairie était bugué. Quelque jours après je recode le module fenêtre de la sfml et le programme ne crash plus.

Je report le bug à mesa 3D et on un gaz me dit que c'est pas leurs bugs et que c'est moi qui ne sait pas utiliser opengl.
Ho mais le code c'est un code que j'ai repris sur Internet et qui fonctionne. Mais pas chez moi. C'est pas parce que qu'un code fonctionne sur une carte graphique et un driver récent qu'il va fonctionner sur une carte graphique plus ancienne et un driver opensource.
Non, toujours crasher la faute, sur les autres.

Et je suis sûr, leur code est tellement danse, qu'ils ne savent même pas ce qu'ils font. Ou ce que fait l'autre car ils sont à plusieurs sur le projet.

Quand il y a un bug, ils ne savent pas comment faire alors ils rejettent la faute sur les autres.

Les gens sont devenus égoïstes et je pense que c'est aussi le cas des développeurs.

Si ça tombe je vais faire ça moi même et ça va fonctionner comme le module fenêtre de SFML.

Mais bon je vais me débrouiller tout seul, ce genre de réponse ça n'aide pas et en plus ça ne répond pas à ma question. C'est dans le seul but de me moinser.
Par contre si j'y arrive, je ne ferai pas de portabilité pour les autres plateformes. Les développeurs n'auront qu'à se débrouiller eux même. Car personellement je commence à être saturé.
Je fais un moteur de jeux qui tourne sur ma plateforme (truc pas simple à faire) parce que unity ne tournait pas.
On vient dire que je code mal. C'était peut être vrai au départ parce que je n'ai fais que l'optimisation à la fin. Mais de là, à dire ce genre de choses, ça c'est quelque chose que je n'accepte pas.