Sommaire
Memory-Mapped Textures: Traduction de la documentation officiel

Avant de commencer, je me suis "amusé" à traduire la documentation mental ray qui y fait référence...

Memory-Mapped Textures

Mental Ray supporte le mappage en mémoire des textures sur les systèmes UNIX et NT.

Le mappage des textures consiste à ne pas charger la texture en mémoire mais à y accéder directement depuis le disque quand le shader en a besoin.

Il n'y a pas d'options spéciales pour en profiter: Si une texture est "mappable en mémoire", mental ray la reconnaîtra et l'utilisera automatiquement.

Seul les fichiers images peuvent être converti en textures "mappable en mémoire" (l'extension de base est .map. Cela dis, les fichiers "mappable en mémoire" sont reconnu même si ils ont une extension différente de .map). Voir la liste des "Output Shaders" (Ndt: dans la doc mental ray) pour une liste des formats de fichier supporté.

Remarquez que le mappage en mémoire est basé sur le principe que les informations sur le disque ne demande pas de décodage ou de conversion, mais sont accessibles dans le format exact que mental ray utilise en interne durant le rendu.

Normalement, mental ray essai de convertir automatiquement les fichiers images qu'il lit en son format d'image interne; Par exemple, si un fichier image est utilisé dans un shader, mental ray va silencieusement convertir les pixels de couleurs en valeur scalaire (0-1).

Du coup, une grande quantité de données (pixel) est converti en un autres type de données (scalaire).

Cela n'est pas le cas pour textures mappé en mémoire, et ce n'est pas le but. Cela s'applique également à l'ordre des octets (Ndt: Dernière phrase technique propre à l'organisation des octets dans la mémoire "Big et Little Endian", pour dire qu'une map converti sur une machine utilisant du big endian ne sera pas compatible avec une machine utilisant du little endian. Mais dans la mesure ou on travail pratiquement que sur station x86 et x64, on s'en fout).

Le mappage en mémoire nécessite plusieurs étapes de préparation:

- La texture doit être convertit au format .map en utilisant un utilitaire comme le imf_copy de mental image. Les chemins de fichier de la scène doit être changé pour aller chercher la nouvelle texture. Remarquez que mental ray reconnait les textures memory mapped mêmé si elles ont une extension différente de .map. Ceci peut être utile pour utiliser les anciens noms de fichiers images avec la "mauvaise" extension, et ce, afin d'éviter à ouvrir et modifier les chemin des fichiers images de la scène. (Ndt: Personnellement, je ne vous conseil pas cette technique)

Lors de l'utilisation de imf_copy, l'option -p est fortement recommandé pour créer une texture en pyramide dans le fichier .map.

- les textures mappé en mémoire sont automatiquement considéré comme étant en local par mental ray, comme si l'option "local" avait été utilisé dans le fichier scène. Cela signifie que si la scène est rendu sur plusieurs machine, chacune d'elle va essayer d'accéder au chemin de l'image donné au lieu de transférer la texture a travers le réseau, ce qui irait à l'encontre du but du mappage en mémoire des textures. Le chemin donné doit être valide sur toute les machine qui participe au rendu. Mental ray support également les textures mappé en "non local": La texture (mappé) est sur le serveur, mais récupérés à travers le réseau par les "esclaves", ce qui simplifie la distribution des scène (Ndt: En rendu) mais peu induire des surcharges réseau inacceptable. (Ndt: En gros, vu que mental ray fait des accès aussi fréquent que si la texture était en mémoire, il pas très conseillé de pointer vers des textures placé en réseau mais plutôt de les avoirs en local, sur chaque machine dédié au rendu. Pour avoir pratiqué le rendu "via le réseau", cela ne pose en fait pas trop de soucis si le réseau en un peu robuste et que le serveur est capable d'encaisser beaucoups d'entrées-sorties.)

- La texture ne dois pas être sur la partition d'un disque utilisant un système de fichier de type NFS (en réseau). Bien que cela évite que les textures doivent exister sur toute les machines, les transferts réseaux réduisent l'efficacité et peuvent facilement rendre le mappage en mémoire plus lent que l'utilisation de textures "tel quel".

- Le mappage en mémoire fonctionne mieux si il s'agit de textures très grandes qui contiennent beaucoup de pixels non utilisés car le fichier de la texture n'est jamais chargé en entier dans la mémoire.

- Une texture mappé en mémoire doit être créé sur une machine avec le même "byte order" que sur la machine qui sera utilisé, où il sera utilisé. Mental ray ne "memorymapera" pas les textures utilisant un byte order incompatible, au lieu de ça, il lira la totalité de la texture placé en mémoire et la convertira. Ce n'est pas efficace et doit être évitée (Ndt: Encore une histoire de little endian et de big endian). Si les textures et la scène sont grandes au point qu'elles ne rentrent pas dans la mémoire physique, et bien le fait de charger une texture revient à:

- Charger le fichier en mémoire
- Le décompresser
- Le copier dans le swap ((Ndt: Sur Unix) Le swap est une partition de disque qui agit comme une extension de la mémoire physique mais sur le disque dur. La vitesse de transfère y est ridicule). (Ndt: Sur windows, c'est le pagefile, la mémoire virtuelle)

Dès lors, l'accès à une texture signifie l'accès au swap, et donc, au disque dur, ce qui fait "ramer" l'ordinateur.

Le mappage en mémoire élimine les étapes de "lecture-décompression-écriture-dans-la-mémoire" et accède à la texture depuis le système de fichiers au lieu du swap.

Cela a pour effet que moins d'espace de swap est nécessaire.

Si la texture et la scène ne sont pas énorme et "rentre" dans la mémoire, et si la texture est fréquemment consultée, les textures memory mapped se révèles légèrement plus lentes que les textures "classiques" (Lire sur le disque est plus long que de lire directement dans la mémoire). Mais pour les grandes textures, le memory mapping est une manière bien plus efficace de charger des textures. Ceci est particulièrement important pour mental ray, qui gère la mémoire comme un cache. Les textures qui ne sont pas memory mapped sont une perte énorme sur le cache, car ils ont tendance à prendre une grandes partie de la mémoire cache. Mental ray a un gestionnaire de cache virtuel séparé qui charge et décharge les textures memory-mapped de manière efficace sans bloquer le cache principal.

Je vous accorde que balancé comme ça, c'est un peu indigeste... :baffed: Mais si j'ai fait cette traduction, c'est parce que j'ai du passer sur cette documentation une bonne dizaine de fois et que malgré qu'elle soit imbuvable, elle est nécessaire à la compréhension du memory mapping dans mental ray...

Donc lisez bien cette version traduite puis lisez ensuite la version anglaise (si vous voulez comprendre les quelques subtilités que j'ai eu du mal à traduire):

Vous connaissez maintenant le principe des "map" (c'est comme ça qu'on les appellera). Avec cette technique, Mental Ray est techniquement capable de manger des textures de taille infini (j'ai essayé 80000x80000, ça passe! :aupoil: ).

Mais comment qu'on fait?

En gros le principe va être de convertir les textures de votre projet en .map et de pointer les textures de vos scène vers ses fichiers nouvellement créés. Et pis c'est tout! En effet, une fois cela fait, mental ray se débrouille très bien tout seul et va reconnaitre les .map et les utiliser comme il se doit. C'est transparent pour l'utilisateur. Sauf que vos barrettes de mémoires vous diront merci (et vos disques dur vont faire la gueule :septic: ).

imf_copy

Comme expliqué dans la documentation, il faut utiliser un utilitaire en ligne de commande: imf_copy. :RTFM:

Il est situé dans:

C:\Program Files\Autodesk\Maya2010\bin\imf_copy.exe

Pour avoir la documentation de ce petit outil, dans Maya, tapez F1 puis naviguez dans:

mental ray -> mental ray for Maya reference -> Apendix (en bas de la page) -> Command Line Interface -> Image Copy: imf_copy

Sinon, le lien complet:

C:\Program Files\Autodesk\Maya2010\docs\Maya2010\en_US\mr\manual\node249.html

C'est le genre de page que je vous invite à placer en favoris :sourit:

imf_copy: Traduction de la documentation officiel

Une fois de plus, je me suis "amusé" à traduire la documentation de cet utilitaire: :baffed:

Image Copy: imf_copy

L'utilitaire de copie et de conversion d'image imf_copy s'utilise de la façon suivante:

imf_copy [options] fichierSource fichierSorti [type de fichier de sorti]

Le fichier "fichierSource" sera copié vers "fichierSorti". Le "type de fichier de sorti" spécifie le format de fichier de "fichierSorti". Si aucun type n'est indiqué, il sera choisi en fonction de l'extension de "fichierSorti". Voir la page "picformats" (Ndt: Dans la documentation mental ray) pour une list des formats supportés. Le format "map" est particulièrement utilisé pour créer des textures "mappable en mémoire". Les options suivantes sont supportés:

-h

Affiche un bref résumé des options.

-p

Créé une texture pyramidale contenant différentes "versions" de la texture. Chaque version est en fait la texture de la version précédente divisé par deux. Le tout est contenu dans un seul fichier. Cette technique (Ndt: très utilisé dans le jeu vidéo, cf: Mipmapping) permet d'obtenir un meilleur anti-aliasing. Voir la page "imfcopyp" (Ndt: Dans la documentation mental ray) pour plus d'informations. Une version de plus en plus petite de l'image est créé a partir de la version précédente (plus grande) en utilsant un filtre de type "box" sur environs 4 pixels.

-v

Verbose. Affiche ce que fait imf_copy quand il est exécuté ainsi que sa version.

-g gamma

Effectue une correction du gamma avec le facteur donné. La valeur par défaut est 1.0.

-q quality

Quand on écrit un fichier JPEG, ce paramettre défini la qualité sur un écart de 1 à 100. La valeur par défaut est 75.

-f filter

Utile uniquement si le fichier de sorti est un .map. La valeur du filter est sauvé dans la texture. Les fichiers de textures "mappable en mémoire" utiliseront cette valeur même si une autre valeur est déclaré dans le .mi ou avec la fonction mi_api_texture_set_filter. (Ndt: Compris que la moitié mais on s'en fout, on ne l'utilise jamais)

-e

Si on souhaite redimensionner une image d'un certain format à un autre format avec moins de bit par pixel, cette option effectue une erreur de diffusion au lieu d'une "troncature" (Ndt: Pas bien compris non plus mais je suppose que c'est quelque chose qui à été ajouté à la suite pour éviter les arrêts du programme sur un problème de conversion de format de pixel. Je ne l'ai jamais utilisé).

-L

Quand on écrit un fichier .map "memorymapped", cette option utilise ordre de byte "little-endian". Pour être efficace le fichiers .map doivent avoir l'ordre des bytes identique à la machine qui les utiliseront (Ndt: sinon elle passeront par l'étape d'ouverture, lecture, écriture sur le swap). Les processeurs de type Alpha et x86 sont de type "little-endian"; La plupart des autres sont de type "big-endian".

-B

Quand on écrit un fichier .map "memorymapped", cette option utilise l'ordre de byte "big-endian".

-r

Quand on écrit un fichier .map "memorymapped", cette option organise les pixels en rectangle au lieu de l'ordre habituel "a la queu-leu-leu". Ceci augmente l'efficacité du cache et réduit l'utilisation de la mémoire pendant le rendu. Les fichiers créés de cette façon ne peuvent être rendu qu'avec mental ray 3.2 et suivant, c'est pourquoi cette option n'est pas activé par défaut. (Ndt: A la lecture de la documentation, on comprend bien que si c'était possible, cette option serait activé par défaut. Utilisez la donc par défaut.)

-c

Quand on écrit un fichier .map "memorymapped", cette option rassemble jusqu'à 20 fichiers donnés pour former une pyramide d'images, mipmap (Ndt: Nous verrons dans un futur billet l'intérêt de cette commande qui nous permettra de fabriquer une "map de debug"). Cette option permet donc de "contrôler" la création de notre .map d'images pyramidales comparé à l'option -p qui créé automatiquement chaque niveau de la pyramide à la moitié de la résolution du niveau précédent en utilisant un filtre de type "box". La première image donnée devra avoir la plus haute résolution, la seconde environs la moitié, la suivante le quart, etc... Les fichiers créés avec cette option peuvent être lu avec n'importe quelle version de mental ray 3.x.

-x N

Extrait le niveau N du .map pyramidale. Le premier (et plus grand) niveau est 0; Le plus élevé est le 19. Cette opération peut être considéré comme l'inverse de l'option -c, mais elle marche également avec des .map pyramidales créés avec -p.

-k K

Quand on écrit un fichier OpenEXR, K définie la methode de compression, ou K peut prendre les valeurs suivantes: none, piz, zip, rle, pxr24. La valeur par défaut est rle.

Convertir nos textures en .map

A la suite de cette traduction, nous somme capable de trouver facilement la ligne de commande à utiliser pour convertir nos textures:

imf_copy -p -r myTexture.png myTexture.map

"easy as one-two-three" :laClasse: Il ne vous reste plus qu'a ouvrir votre scènes et à pointer vers vos nouvelles textures ".map" et mental ray se chargera tout seul du reste.

Suite?

Ce billet introduit quelques autres billets que je compte faire (un jour :siffle2: ). Voici un aperçu:

  • Script qui génère automatiquement les versions .map des fichiers images en comparant leurs ages. Et ce, dans toute la hiérarchie d'un dossier donné (récursif).
  • Création d'un fichier .map de debug qui affiche une image différente à chaque niveau de la texture pyramidale.
  • Analyse et optimisation du fonctionnement de "mental ray for Maya" grâce à la map de debug que nous auront créé.
  • Surement d'autres trucs...

Voila, j'espère que ce billet en aidera quelques uns d'entre vous. N'hésitez pas à me faire remarqué si je n'ai pas été assez clair ou si vous pensez que certains points méritent quelques éclaircissements.

A bientôt!