Tile Rendering: Optimiser le rapport prix / temps de rendu
Le rendu tile qu’est-ce que c’est ?
Le rendu tile consiste à fractionner la zone de rendu d’une caméra 3D pour permettre de rendre une image sur plusieurs serveurs (ou sur une seule machine en plusieurs rendus). Puis de réassembler les morceaux à l’aide d’un outils tiers. Chaque serveur aura donc moins de pixels à calculer
Le rendu fractionné possède plusieurs appellations tel que multibande, rendu strip, crop rendering ou encore tile rendering. Ainsi une fraction du rendu est variablement appelée bande, strip, crop ou tile.
Pour quel usage ?
Rendre une image en très grande résolution est bien souvent long, coûteux et nécessite beaucoup de ressource mémoire. Les utilisateurs de ferme de rendu tel que RANCH Computing, cherchent à gagner du temps sans avoir à investir dans plus de matériel. Il est donc important qu’ils puissent maitriser leurs budgets. Dans cette perspective nous nous sommes penchées sur la question de la meilleure division d’une image.
De prime abord on pourrait penser que plus le nombre de serveurs travaillant sur une image sera important, plus cela sera avantageux. Cependant, chaque serveur qui calcule une portion de la frame devra charger la scène, et ce temps restera quasiment identique quelle que soit la résolution de la tile. De fait, les artistes étant facturé en fonction du temps de rendu total, il est important de bien choisir le nombre de découpe. Une découpe trop grande pourrait prendre trop de temps à rendre, voir ne pas se rendre du tout si le projet dépasse la mémoire du serveur. Tandis qu’une découpe trop fine pourrait entrainer des surcoûts non-désirable pour les clients.
Cas pratique
Etudions un cas pratique. Nous prenons comme témoin un projet GPU, car ces derniers étant plus rapide à rendre, ils ont une plus grande sensibilité aux différents facteurs
Les tests ont été réalisés selon caractéristiques suivantes :
- 1 seul type de serveur disposant d’un processeur Dual Xeon E5-2690 V4, de 128 GO de RAM et de 4 cartes RTX 3090 disposant de 24GO de VRAM.
- 1 scène de référence rendu sans découpe en plusieurs résolutions :
Resolution | Number of pixels |
---|---|
1920×1080 | 2,073,600 px |
3840×2160 | 8,294,400 px |
7680×8640 | 33,177,600 px |
15360×8640 | 132,710,400 px |
30720×17280 | 530,841,600 px |
- La scène de référence rendu en diverse découpe de même taille pour chacune des résolutions, la longueur reste fixe :
2 tiles | 3 tiles | 4 tiles | 6 tiles | 12 tiles |
---|
Le temps de rendu
Commençons par analyser les temps de rendu nécessaire pour chacune des résolutions de notre scène de référence. Dans le tableau suivant, nous avons inscrit le temps de rendu global pour rendre toutes les bandes de la résolution donnée. C’est-à-dire, lorsque toutes les tiles sont rendus en parallèle, la durée de rendu de la tile la plus longue à rendre.
Time (s) | 2k | 4k | 8k | 15k | 30k |
---|---|---|---|---|---|
Image entière | 174 | 342 | 1022 | 3744 | / |
2 tiles | 159 | 230 | 591 | 2121 | / |
3 tiles | 131 | 189 | 459 | 1579 | 168938 |
4 tiles | 118 | 171 | 332 | 1353 | 4455 |
6 tiles | 135 | 148 | 278 | 873 | 3029 |
12 tiles | 128 | 134 | 203 | 517 | 1579 |
On constate sans surprise que plus il y a de découpe, plus le temps de rendu est décroissant. Cependant, on peut également relever que cette diminution de la durée du rendu n’est pas linéaire, même en ignorant les résultats chaotiques du rendu en 30k.
Il y a un gain de temps assez net entre l’image entière et divisé en 2, puis ce gain de temps se lisse au fur et à mesure que l’on augmente le nombre de découpe.
Ces rendus permettent également de constater que bien que le nombre de pixel soit le même entre une résolution et 1 tile du rendu au double de la résolution découpé en 4 tiles, les temps de rendu ne sont pas strictement identiques. Cette différence s’explique essentiellement parce que les pixels ne sont pas les mêmes.
Il est également bon de noter que toutes les tiles d’une même résolution et d’un même fractionnement n’ont pas les mêmes temps de rendu, et ceux pour les mêmes raisons que cité juste avant.
La mémoire
Jetons maintenant un œil à l’utilisation mémoire. Lors du rendu d’un projet GPU, c’est la mémoire de la carte graphique qui va faire l’essentiel. Cette mémoire est communément appelée VRAM (Video Random Access Memory), et est à différencier de la RAM (Random Access Memory). La VRAM ne peut être modifié qu’en changeant le modèle de carte graphique pour un modèle possédant plus de mémoire vidéo. La plupart des GPU moyenne et haute gamme ont entre 8Go et 24GO de VRAM.
Vous pouvez voir ici le comparatif des cartes graphiques et leurs mémoires respectives :
- Cartes NVIDIA : https://www.nvidia.com/fr-fr/geforce/graphics-cards/compare/
- Cartes AMD : https://www.amd.com/en/products/specifications/graphics.html
Comme l’utilisation de la mémoire vive peut fluctuer lors d’un rendu, nous avons relevé dans ce tableau le pique le plus élevé de la consommation mémorielle.
VRAM (MB) | 2k | 4k | 8k | 15k | 30k |
---|---|---|---|---|---|
Image entière | 5435 | 6107 | 8697 | 19302 | OUT |
2 tiles | 5221 | 5579 | 6943 | 12115 | OUT |
3 tiles | 5221 | 5443 | 6319 | 9831 | 24169 |
4 tiles | 5063 | 5359 | 6032 | 8689 | 20441 |
6 tiles | 5097 | 5245 | 5745 | 7495 | 15403 |
12 tiles | 4925 | 5103 | 5441 | 6397 | 10325 |
On remarque que plus l’on augmente la résolution, plus les écarts d’utilisation de la VRAM entre les différentes découpes se creusent. L’écart n’est que de 500 MO environ entre l’image entière et la découpe 12 tiles en 2K. Cependant, si on regarde l’image en 15K, on s’aperçoit que l’utilisation de la mémoire a été divisé par 3.
Par ailleurs, comme indiqué dans les caractéristiques du test, notre GPU de référence possède 24 GO de mémoire. Pour cette raison, le rendu dans la plus grosse résolution à échouer à rendre l’image entière ainsi que découpé en 2 tiles (265 420 800 px). De plus, le rendu en 3 tiles a été bien plus laborieux que le reste des autres rendus. En effet, sur les 3 bandes, seul 2 se sont rendus et avec des temps de rendu exorbitants. Les 24 GO de VRAM sont utilisés pour le rendu, de ce fait, le moteur de rendu à swapper sur la RAM. Cependant, ce processus ne permet pour l’instant pas d’utiliser complétement les deux types de mémoire vive et ralenti considérablement les performances du rendu. Il est intéressant de noter que la découpe en 12 tiles permet de passer sous la barre symbolique des 11 GO de VRAM qui permet de rendre sur n’importe quel serveur GPU du RANCH.
Bien que lors d’un rendu GPU, l’utilisation de la RAM est souvent moins critique, il est tout de même bon de noter qu’elle n’est pas à négligé. D’une part, le chargement d’une scène se fait en CPU donc en utilisant la RAM. D’autre part, certain processus reste dépendant de la RAM durant le rendu.
Un ordinateur qui n’aurait que 16GO de de RAM par exemple, ne serait alors pas en mesure de rendre certaines résolutions de tiles malgré la présence d’un GPU disposant de suffisamment de VRAM.
RAM (MB) | 2k | 4k | 8k | 15k | 30k |
---|---|---|---|---|---|
Entire image | 6150 | 7159 | 11804 | 30579 | OUT |
2 tiles | 5913 | 6448 | 8717 | 18067 | OUT |
3 tiles | 5737 | 6130 | 7718 | 13578 | 46785 |
4 tiles | 5682 | 6009 | 7270 | 11510 | 35527 |
6 tiles | 5717 | 5862 | 6651 | 9803 | 25624 |
12 tiles | 5510 | 5830 | 6109 | 7473 | 15733 |
Au même titre que la VRAM, la consommation de RAM est descendante en augmentant le nombre de découpe et croissante en augmentant la résolution.
Le coût
Et maintenant parlons des coûts qu’engendre de tel rendu au regard du temps de rendu. De base un RANCH Credits (RC) équivaut à 1€ mais cela peut être moins en cas de recharge importante ou de promotion. L’utilisateur étant facturé pour le temps d’utilisation des serveurs, il est logique de voir des courbes qui suivent la même tendance.
On remarque que la différence de prix entre l’image rendu sur un seul serveur et sur 12 serveurs est en moyenne de 5-6 credits pour ce rendu.
Cependant la différence de prix est à mettre en corrélation avec le gain de temps entre 2 découpes. Pour une image en 2k, découpé en 12 parties revient 86% plus cher pour un rendu de 26% plus rapide. Avec de tel écart, il n’est pas du tout intéressant d’opter pour un rendu fractionné pour gagner une poigné de seconde.
En revanche, ces proportions s’inversent pour le rendu en 15K. L’augmentation du prix est de 24% tandis que le rendu se fait 86% plus rapidement. Quand le temps vient à manquer et que le budget le permet, opter pour un rendu tile sera donc bien plus intéressant.
Et bien sûr dans certain cas, comme celui de notre image en 30k, il ne s’agit plus uniquement de pouvoir rendre plus rapidement mais tout simplement de pouvoir rendre. Le minimum de découpe, pour pouvoir rendre cette image entièrement sur notre serveur de référence, est de 4 en raison de la limite technique à 24Go de VRAM. En comparant l’augmentation du prix entre 4 et 6 tiles, nous n’obtenons qu’un écart 1,14 RC soit une augmentation de moins d’1%, pour un gain de temps de rendu de 23min46s soit un rendu 32% plus rapide. Entre 6 et 12 tiles, l’augmentation du prix passe à un peu moins de 6% et le gain de temps de rendu et de 24min10 soit presque 48%, cependant il y a 3 fois plus de tiles que la comparaison précédente. Si l’on ramène à la même échelle, cela revient à une augmentation de moins de 2% et un rendu 16% plus rapide par tranche de 2 tiles, soit un écart de 1,91 RC et 8min03. Le gain de temps est donc intéressant mais moins que le fait de passer de 4 à 6 découpes. Au final, l’écart de prix entre 4 et 12 tiles est de moins de 7% (6,54 RC) pour un gain de temps de rendu de plus de ¾ d’heure soit presque 65%.
Si l’on fait le même comparatif pour l’image en 15K, la première chose que l’on remarque est qu’entre 4 à 6 tiles le gain de temps de rendu est grossièrement le même que pour 30K, cependant le prix du projet à 6 tiles est moins cher que celui à 4 tiles. Cette différence s’explique par le fait que le temps de calcul cumulé de chacun des serveurs est inférieur du fait de la rapidité de rendu de certaines partie de l’image. En d’autre mots, si toutes les tiles d’une même découpe étaient rendus sur un seul serveur, le temps de rendu de la découpe en 4 serait légérement supérieur que celui de la découpe en 6.
15K – Durée | 4 serveurs | 6 serveurs |
---|---|---|
tile 1 | 00:16:58 | 00:11:14 |
tile 2 | 00:19:19 | 00:13:05 |
tile 3 | 00:22:33 | 00:13:56 |
tile 4 | 00:15:16 | 00:13:04 |
tile 5 | – | 00:11:34 |
tile 6 | – | 00:10:53 |
TOTAL | 01:14:06 | 01:13:46 |
Il est a noté toutefois que notre priorité GPU-Low comprends un mélange de serveur contenant des RTX 3090 et des RTX 2080ti qui n’ont que 11GO de VRAM. Selon l’utilisation mémoire, il peut être nécessaire de choisir une priorité GPU-24 garantissant d’avoir 24GO de mémoire.
Conclusion
Si l’on parle en termes de coût uniquement, il sera toujours plus intéressant de rendre l’image entière lorsque cela est techniquement possible. Inversement, si l’on ne parle que du temps de rendu, il est plus avantageux d’augmenter le nombre de découpe. On soulignera toutefois que plus l’écart entre le nombre de pixel à calculer sera important plus le gain sur le temps de rendu sera manifeste.
Notre cas pratique met en lumière une réalité technique globale mais ne reflète bien évidemment pas l’ensemble des scènes. Chaque scène étant différente, elles auront des complexités de calculs différentes et le rendu d’une scène en 2K sera parfois plus long que celui d’une autre scène en 4K. Il appartient donc au créateur qui veut externaliser son rendu, de connaitre sa scène pour bien déterminer s’il est plus intéressant d’investir dans plus de rapidité. Le premier choix logique demeurera celui des contraintes techniques matériels. Au-delà de ça il sera surement préférable de privilégier moins de découpe pour optimiser les coûts pour des frames longues à rendre de résolutions standard (2k, 4k). Tandis que pour de forte résolution, plus de découpe permettra de réduire fortement le temps de rendu sans que le surcoût ne soit significatif.
L’idéal serait de pouvoir déterminer des zones de tailles différente en fonction de la complexité de certaine partie d’une image pour faciliter le calcul et uniformiser les temps de rendu. Actuellement, il n’est pas possible de déterminer automatiquement et de manière efficace ces zones. Cependant, avec les progrès de l’intelligence artificiel et des moteurs de rendu, il est plus que probable qu’à l’avenir cette fonctionnalité soit réalisable.