test10 - leurres

[abakleriche]

Il s'agit d'un test mettant en oeuvre un leurre générique. Je te fournis les deux "scénarios" pour setk_player, obtenus par enregistrement des appels au toolkit lors de l'utilisation de VISEO. test10_player_fast.zip test10_player_ray.zip

Avec SE-RAY, le test se passe bien. J'ai mis dans le dossier l'image obtenue par VISEO et celle par le rejeu setk_player.

Avec SE-FAST, on a un plantage très rapidement (cf. le peu d'appels au toolkit dans le fichier log). Ce plantage se reproduit avec setk_player.

[apajot]

J'ai corrigé des choses, je t'ai mis à disposition un correctif : ABAK_170630.zip tu peux le supprimer une fois que tu l'as récupéré.

[abakleriche]

Plus de plantage avec SE-FAST sur le test de base. Je te joins une version du test (en mode player) qui inclut un objet censé être éclairé par le leurre. J'ai exécuté le player avec -user_radiance 100 pour avoir un leurre assez lumineux (dans le player, cette luminance sert aussi bien pour la callback de représentation de l'objet que pour la callback utilisée pour l'effet éclairant). Avec SE-RAY, on observe nettement la réflexion du leurre sur l'objet, mais pas avec SE-FAST. test10_player_ray.zip test10_player_fast.zip

[apajot]

C'est corrigé, une étourderie dans le toolkit ! Le correctif est dispo.

[abakleriche]

OK ça marche.

Par contre (excuse moi de t'ennuyer encore), j'ai un troisième volet dans le test qui réalise une séquence d'images (avion + leurre) en bibande, en 600x600. Avec SE-FAST, je plante en général à la deuxième génération de scène (ou quelquefois à la troisième ou quatrième). En creusant un peu, j'ai remarqué que l'appel à seTkOptronicSignalGetSignalRadincesBuffer rend une taille de 720000 avec SE-RAY, ce qui semble normal : 600x600x2, et seulement 360000 avec SE-FAST. Par contre, je récupère bien les 2 bandes. Le problème ne vient a priori pas de là, même si cela semble anormal. Je suis repassé en monobande pour simplifier le problème et je plante toujours à la deuxième génération de scène. Je te joins le fichier pour le player. test10_seq_player_fast.zip

[apajot]

Quand ca crashe tu ne m'embêtes pas, c'est le crash qui m'embête ! :) Je regarde.

[apajot]

mince, ca ne crashe pas...tu saurais reconstituer ce que devrait contenir le log pour l'appel d'après le second RenderSignal ? Et si tu as le log en multibande, que je regarde cette histoire de taille....merci !

[abakleriche]

Le 03/07/2017 à 17:19, apajot a écrit :

mince, ca ne crashe pas...tu saurais reconstituer ce que devrait contenir le log pour l'appel d'après le second RenderSignal ? Et si tu as le log en multibande, que je regarde cette histoire de taille....merci !

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apajot/voc/issues/4#issuecomment-312673626, or mute the thread https://github.com/notifications/unsubscribe-auth/AcSU2q78Nbt05SJSnfI-7E9UR1UNyfiFks5sKQZmgaJpZM4OIBrG.

Dans VISEO, le crash a lieu pendant l'appel au RenderSignal. Le problème est que ça à l'aire un peu aléatoire : je viens de le rejouer, j'ai planté au troisième et non plus au second.

Je vais te faire un log bibande

[apajot]

Pour la taille des buffers, je viens juste de corriger. Je te fournirai le correctif au prochain gros truc, sauf si tu préfères l'avoir tout de suite (ca n'avait pas d'impact en interne).

[abakleriche]

Le 03/07/2017 à 17:48, apajot a écrit :

Pour la taille des buffers, je viens juste de corrigr. Je te fournirai le correctif au prochain gros truc, sauf si tu préfères l'avoir tout de suite.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apajot/voc/issues/4#issuecomment-312680304, or mute the thread https://github.com/notifications/unsubscribe-auth/AcSU2pNtzb_M7SM5BzSrUTkoE9icJz9hks5sKQ1WgaJpZM4OIBrG.

Si ça n'influe sur rien d'autre, il n'y a pas urgence (le buffer était sans doute correctement alloué ?)

[apajot]

oui

[abakleriche]

Du coup je ne t'envoie pas le log du bibande ?

Chez moi non plus, ça ne plante pas en mode player. J'ai essayé de créer un log avec SE-RAY, puis de le bricoler pour le jouer en SE-FAST (remplacement du paramètre à l'initialisation, suppression de la demande de "bande intégrée" spécifique à SE-RAY). Remarque en passant : quand on compare un log SE-RAY avec un log SE-FAST, on voit que les handles de UserMaterial rendus sont très différents : dans SE-RAY, cela semble être de vrais pointeurs, alors que dans SE-FAST, cela semble être des entiers qui commencent à 1 et s'incrémentent. Je te dis ça à tout hasard, il y a sans doute une bonne raison. Lorsque j'exécute ce log dans le player, je plante sur le second appel à seTkMaterialNewUserMaterial, donc bien avant le RenderSignal. Je te joins les deux log (le vrai fait par SE-FAST, et le faux fait par SE-RAY puis bricolé). C'est bizarre ce plantage, mais je ne vois pas ce que j'aurais pu oublier en transformant mon log se-ray en log se-fast. J'espère que cela pourra t'aider logs.zip

[apajot]

Pour le bibande non en effet pas besoin ! Pour les handles qui sont très différents, oui c'est tout à fait normal :) étrange pour le plantage du coup...je t'ai mis une version en debug de la dll avec le pdb, comme ca tu auras une pile que tu pourras me faire parvenir quand ca crashera. En attendant je regarde les 2 logs.

[apajot]

Je suis tombé sur une coquille dans le tkgeom, je viens de la corriger, je ne sais pas si ca explique ton bug (je ne pense pas) mais en tout cas ca pouvait causer des crashs ! Du coup t'as un petit paquet avec _2, toujours en version de debug. Et tant que j'y pense, est-ce-que ca pourrait être dû à un problème de parallélisme ? Si le chargement parallèle des données n'est pas désactivé, il peut y avoir plusieurs appels à des callbacks en même temps, depuis plusieurs threads. Je me souviens que Paul m'avait dit que tu l'avais désactivé parce que tu avais des deadlocks, est-ce toujours le cas ?

EDIT : bonne nouvelle (enfin si on veut), ca crashe avec le vrai log et ca pourrait expliquer tes crashs, je vais corriger ca.

[abakleriche]

Ci-joint la pile d'appel au moment du plantage (scénario monobande). Le plantage a lieu lors du calcul de la seconde image call_stack.txt La notion de chargement des données en parallèle ne me dit rien du tout. Je n'ai jamais eu de deadlocks. Paul doit confondre avec quelqu'un d'autre. Comme désactive-t-on cette fonction ?

[apajot]

Ah super, c'est ce que je viens juste de corriger et d'uploader (_3). Ah ok, pour le désactiver il faut définir la variable d'environnement SE_PARALLEL_TASKS_EXECUTOR_DISABLE=1

[abakleriche]

On progresse ! Avec cette version, j'ai un plantage dans mes fonctions de callback. En effet, mes fonctions de callback ne sont pas threadsafe. Du coup j'ai désactivé l'exécution parallèle et ça va nettement mieux. Il reste un plantage dans le seTkFinalise. Pile d'appels ci-joint. call_stack.txt Pour ma gouverne

• SE-RAY n'utilise pas le calcul parallèle à ce niveau ?
• Est-ce très pénalisant de désactiver le calcul parallèle ?

[apajot]

Ah parfait ! Je vois en gros à quoi le crash est dû, pourrais-tu m'envoyer le log qui me permettrait de reproduire rapidement les conditions du crash ? merci !

Pour le parallélisme, pour SE-RAY je ne saurais te dire, mais si c'est le cas je pense surtout que c'est beaucoup plus diffus : SE-FAST-IR-V4 lance tous les threads à dispo pour interroger les callbacks, là où dans SE-RAY c'est noyé dans le reste du code de raytracing. Oui c'est pénalisant de le couper entièrement pour les temps de chargement, car pour l'instant ca coupe toute possibilité de parallélisme, meme pour les calculs de compilation spectrale qui sont lourds. Mais je viens de me souvenir qu'on avait eu le soucis lors de nos tests, et qu'on avait introduit une variable d'environnement beaucoup plus ciblée : SE_PARALLEL_TASKS_EXECUTOR_DISABLE_FOR_USER_MATERIALS

[abakleriche]

J'ai changé la variable pour SE_PARALLEL_TASKS_EXECUTOR_DISABLE_FOR_USER_MATERIAL et ça marche pareil. Donc ça ne devrait plus être trop pénalisant. Ci-joint le log d'exécution

test10_fast.zip

[apajot]

Crash corrigé, on ne nettoyait pas proprement les objets ajoutés par le TK-GEOM. J'ai uploadé le correctif ! si tu me confirmes que ca marche je te referai une version optim.

[abakleriche]

OK ça marche, j'attends la version release pour clore.

[apajot]

C'est uploadé (_2).

[abakleriche]

C'est bon je clos.

[abakleriche]

Il s'agit du volet "séquence d'images" du test 10. Il fonctionne bien sous Linux Red hat 5.4 32 bits (les 10 images sont générées). Il plante sous Windows 32 bits, lors de la génération de la seconde image. Lors du calcul de la seconde image, des messages "Error : Task-executor : bad allocation" apparaissent dans la console, puis plantage. Ci -joint un log pour setk_player test10.zip

[apajot]

J'ai corrigé (politique d'allocation un peu trop agressive pour windows), ce qui m'a d'ailleurs permis de voir pourquoi je n'arrivais pas à détecter correctement les exceptions dans le cas d'exécution mult-threadée, qui amenaient à des deadlocks (corrigé aussi). Veux-tu une mise à jour immédiate ?

[abakleriche]

Je veux bien une mise à jour, sauf si tu as autre chose à y intégrer dans les tous prochains jours.

[apajot]

Lalaina est en train de regarder le problème du bi-leurre, en fonction du temps qu'il estime nécessaire je te livrerai avec ou sans sa correction.

[apajot]

J'ai uploadé un patch (ABAK_20170829.zip) contenant le nécessaire pour les dernières corrections en Win32 et Rhe55 (sous-pixellique, bad alloc, bileurre). Par contre il se peut que les scripts inclus dans des scnx utilisés comme objets ne fonctionnent plus, Lalaina est en train de regarder ca. Par contre, pourrais-tu effacer les mises à jour ABAK que j'ai mises sur le ftp et dont tu ne te serviras pas stp ?

[abakleriche]

Ca marche. Je clos.