[Index Software] Coin des développeurs :]

[Tugdual]

Quand je pense que j'ai failli raté ça :
-> Le premier compilateur C++ fête ses 30 ans ...

[Bubu]

Quelqu'un a déjà utilisé Open CL ? Si oui, avec quel IDE ? Il y a-t-il de bonnes libraires mathématiques (algébre linéaire et quaternions)
(Ce serait pour faire un moteur de rendu en lancer de rayons temps différé, pensez-vous que c'est adapté ?)
Merci

[Tugdual]

Non, je n'ai pas utilisé.

Mais juste une question, parce qu'un truc me gratte ...
"OpenCL", c'est pour les applications maths et généralistes, non ?
Pour les applications graphiques, ce n'est pas "OpenGL" ?

[Benoit]

Une vidéo de démo et un exemple (en anglais) :

http://www.gamedev.net/blog/1241/entry- ... -opencl-i/

[Bubu]

Non, je n'ai pas utilisé.

Mais juste une question, parce qu'un truc me gratte ...
"OpenCL", c'est pour les applications maths et généralistes, non ?
Pour les applications graphiques, ce n'est pas "OpenGL" ?

Merci quand-même (je crois que je vais devoir passer par un site spécialisé)

Pour le rendu en lancer de rayon (en simplifiant beaucoup tu lances un rayon passant par chaque pixel et tu regardes ce qu'il touche), OpenGL et DirectX ne sont pas adaptés, (car rendu basé sur la rasterisation. remplissage de triangles)

Oui, c'est Computing Library et non Graphic Library.
C'est un peu comme CUDA, mais libre.
Le problème que j'ai c'est surtout de trouver une librairie pour charger des assets (triangle meshes). En C++ j'utilisais Assimp (librairie géniale qui prend en compte la plupart des formats), mais là ...

[Bubu]

Une vidéo de démo et un exemple (en anglais) :

http://www.gamedev.net/blog/1241/entry- ... -opencl-i/

Merci Benoit, c'est effectivement sur ce site que je pensais aller

[Ixy]

La tu demandes quelque chose de très specifique je crois pas qu on puisse te venir en aide

[Bubu]

La tu demandes quelque chose de très specifique je crois pas qu on puisse te venir en aide

Bah j'ai tenté ma chance.

@Benoit : lien très intéréssant pour voir un exemple d'utilisation d'OpenCL ... par contre je trouve qu'il exagère de parler de temps réel avec une scène pareille (intersection ray-sphere et ray-plane c'est trivial, même un rendu 100% cpu d'une scène si simple peut être fait en temps réel à mon avis). J'aurais été bluffé qu'il arrive à gérer une scene plus complexe (composée de triangle meshes) en temps réel.
Pour une "vraie" scene, il faut utiliser des octrees ou bvh pour partitionner la scène au niveau triangle sinon en force brute .... même pas en rêve. Du coup c'est plus compliqué (mais plus intéréssant aussi)
Mais c'est quand même très intéressant, merci.

[Benoit]

Je pense que c'est le principe (et la technique de programmation) qui fait qu'on appelle ça du "temps réel".

Par opposition, il y a des moteurs qui font du ray tracing en "temps différé" sans rendu graphique (par exemple pour les simulations de canaux de transmission vers les téléphones portables), mais je ne sais pas trop comment on les appelle/catégorise.

[Bubu]

Je pense que c'est le principe (et la technique de programmation) qui fait qu'on appelle ça du "temps réel".

Par opposition, il y a des moteurs qui font du ray tracing en "temps différé" sans rendu graphique (par exemple pour les simulations de canaux de transmission vers les téléphones portables), mais je ne sais pas trop comment on les appelle/catégorise.

(Désolé de remettre ce sujet en haut, mais j'en crevais d'envie ... )
La notion de systèmes temps réel est encore plus stricte : à la fac, en master, j'ai suivi un cours "Systèmes temps réels", (aussi chiant que possible, par un prof aussi puéril que stupide ...) en gros, il est surtout question d'échéance de tâches, il faut s'assurer que chaque tâche respecte absolument son échéance, sinon c'est foutu, le système n'est pas en temps réel. Quand un pilote d'avion commande l'ouverture des trains d'atterrissage, on ne peut se permettre d'avoir un "now loading, please wait".
Dans ce sens, aucun rendu 3D utilisant la rasterization ne peut être dit temps réel car on ne garanti pas qu'une frame soit rendue dans un temps fixe, précis, à l'avance.
Pour pouvoir qualifier un moteur de rendu de "temps réel", il faudrait s'assurer que chaque rendu de frame prenne (au) moins de temps que le rafraîchissement de l'écran (1 / 30 s, voire plutôt 1 / 60 s), ce qui n'est clairement pas respecté, d'où un frame rate fluctuant, voire saccadé pour l'oeil humain selon les jeux et la configuration du rendu.

Dans un sens souple, (qui est le mien), on peut dire que le rendu du programme du mec est bien temps réel, mais je voulais dire que nommer son article "realtime raytracing" fait surtout vendeur, promotionnel, car dès qu'il intégrerait un rendu de scène moyen, standard, de géométrie usuelle, son programme saccaderait à mort. J'ai lu un article où le rendu de l'image d'une scène riche, en résolution 4K, prenait 9h30 ...

Sinon, j'ai enfin compris que je pouvais utiliser le C++ et OpenCL, c'est un peu le même principe qu'avec les shaders, il y a un programme dans n'importe quel langage (qui prépare les données) et le programme OpenCL (qui traite ces données).

Merci encore Benoit.

[Benoit]

Un système temps réel (même critique) n'a pas besoin que toutes les tâches soient couronnées de succès, l'important c'est qu'elles rendent la main et un résultat quand le temps qui leur est accordé est écoulé (de toute façon on ne leur en laisse pas le choix).

Si la technique présentée ici peut donner des temps de calculs aussi long, effectivement il y a comme une arnaque.

[Bubu]

Un système temps réel (même critique) n'a pas besoin que toutes les tâches soient couronnées de succès, l'important c'est qu'elles rendent la main et un résultat quand le temps qui leur est accordé est écoulé (de toute façon on ne leur en laisse pas le choix).

Bah si, d'après les connards dont je tire tristement l'enseignement (et que j'aimerais respecter s'ils étaient plus gentils .... est-ce difficile ? Apparemment oui )... encore si. Si dans un système multi-tâches, une tâche à sa fin n'arrive pas dans l'échéance, c'est foutu, il faut tout reconstruire le système.
Ces mecs là passent plus de temps à prouver (mathématiquement) que chaque tâche aboutit avant l'échéance quelle que soit la situation, qu'a programmer . (Ce n'est pas un défaut, c'est leur boulot)

Mais je m'en fous, dans ce qui m'interesse, tu as complètement raison...
Y-a-t-il une nuance entre temps réel et temps différé ?

Encore mille fois merci Benoit

[Benoit]

Un système temps réel (même critique) n'a pas besoin que toutes les tâches soient couronnées de succès, l'important c'est qu'elles rendent la main et un résultat quand le temps qui leur est accordé est écoulé (de toute façon on ne leur en laisse pas le choix).

Bah si, d'après les connards dont je tire tristement l'enseignement (et que j'aimerais respecter s'ils étaient plus gentils .... est-ce difficile ? Apparemment oui )... encore si. Si dans un système multi-tâches, une tâche à sa fin n'arrive pas dans l'échéance, c'est foutu, il faut tout reconstruire le système.
Ces mecs là passent plus de temps à prouver (mathématiquement) que chaque tâche aboutit avant l'échéance quelle que soit la situation, qu'a programmer . (Ce n'est pas un défaut, c'est leur boulot)

C'est sûrement une façon valide de traiter beaucoup de problèmes (surtout pour des tâches simples et à temps déterminé).

Dans le cas où les traitements sont à temps déjà moins déterminés, c'est un peu excessif de dimensionner un système (parce que l'approche revient à cela) en fonction d'un scénario de traitement très peu probable (surtout que de plus en plus de mécanismes à longue traine apparaissent). Ça implique d'acheter un matériel couteux pour que la majorité du temps, il ne serve à rien.

Mais je m'en fous, dans ce qui m'interesse, tu as complètement raison...
Y-a-t-il une nuance entre temps réel et temps différé ?

Il me semble qu'on ne parle plus de Td que pour les tâches en batch, par exemple les traitements qu'on met en file d'attente sur un gros calculateur et qu'on laisse traiter par un échéancier.
C'est pas du tout le même usage, on est plutôt dans du gros traitement qui tâche.

[Benoit]

Niveau de compétence moyen neurotypique, grosse boite française.

Pb complexe => Insoluble ou compliqué => programme pourri qui met 2h quand il marche, ou utilise un logiciel où le tutoriel commence page 1045 du manuel.

Niveau de compétence S.A. => resolution d'une dizaine de ces problèmes par seconde.

Devinez qui est harcelé entre les deux...

[Tugdual]

Différentes types de développeurs :

DmitryNarozhny_dev.jpg

Source : IT-characters ...