Qu'est-ce que le rendu GPU. Quel rendu est le meilleur ? rendus biaisés et impartiaux
Comment créer un moteur de rendu qui fonctionnerait même sur l'ordinateur de votre grand-mère ? Au départ, nous étions confrontés à une tâche légèrement différente : créer un rendu impartial pour tous les modèles de GPU : NVidia, ATI, Intel.
Bien que l'idée d'un tel rendu pour toutes les cartes vidéo soit dans l'air depuis longtemps, elle n'a pas encore abouti à une implémentation de haute qualité, en particulier sur Direct3D. Dans notre travail, nous avons trouvé une combinaison très sauvage et nous vous expliquerons plus en détail ce qui nous y a conduit et comment cela fonctionne.
Marchevsky a très bien expliqué ce qu'est le rendu impartial, ou le rendu sans hypothèses, dans une série d'articles.
"Traçage de chemin sur GPU" partie 1, partie 2 et "Rendu impartial (rendu sans hypothèses)".
Bref : c'est un rendu qui n'apporte rien erreurs systématiques dans le calcul et reproduit des effets physiquement précis
- illumination globale
- ombres douces, reflets réalistes
- profondeur de champ et flou de mouvement
- diffusion souterraine et plus encore
En raison de l’authenticité physique et de la qualité de l’image, cette approche est évidemment très gourmande en ressources. Le problème peut être résolu en transférant les calculs vers le GPU, car cette approche augmente la vitesse de calcul jusqu'à 50 fois pour chaque périphérique GPU.
1200x600 (cliquable), AMD Radeon HD 6870, temps de rendu : 9 minutes
Pourquoi Direct3D
Il existe de nombreuses plateformes GPGPU (OpenCL, CUDA, FireStream, DirectCompute, C++ AMP, Shaders, etc.), mais il existe une controverse autour de choix optimal Ils sont toujours d’actualité et il n’y a pas de réponse claire sur ce qu’il est préférable d’utiliser. Regardons les principaux arguments en faveur de Direct3D, qui nous ont persuadés de choisir cette API particulière :- Fonctionne sur toute la gamme de cartes vidéo, émulé sur tous les modèles de processeurs : le même shader fonctionne partout
- Ce sont les spécifications Direct3D qui fixent l’orientation du développement du matériel grand public.
- Toujours le premier à recevoir les pilotes les plus récents et les plus stables
- Les autres technologies multifournisseurs ne sont pas stables ou sont mal prises en charge
La combinaison OpenGL/GLSL a également été envisagée, mais a été rapidement abandonnée en raison des limitations que DirectX résout grâce à DirectCompute (problèmes de traçage de chemin bidirectionnel, etc.).
Nous notons également la situation des pilotes GPGPU pour le matériel grand public, qui sont publiés tardivement et mettent beaucoup de temps à atteindre la stabilité. Ainsi, lorsque la gamme NVIDIA Kepler 600 est sortie, les joueurs ont immédiatement reçu des pilotes Direct3D de haute qualité et des machines de jeu plus puissantes, mais la plupart Les applications GPGPU ont perdu leur compatibilité ou sont devenues moins efficaces. Par exemple, Octane Render et Arion Render, construits sur CUDA, ont commencé à prendre en charge la ligne Kepler l'autre jour. De plus, le matériel GPGPU professionnel n'est pas toujours bien meilleur dans un certain nombre de tâches, comme décrit dans l'article « NVidia pour les applications 3D professionnelles ». Cela donne une raison de collecter poste de travail spécifiquement sur le matériel de jeu grand public.
Pourquoi pas Direct3D
Dans toutes les annonces de DirectX 10‒11, ils écrivent que les nouveaux modèles de shaders sont idéaux pour le lancer de rayons et de nombreuses autres tâches GPGPU. Mais personne n’a vraiment profité de cette opportunité. Pourquoi?- Aucun outil ni support
- La recherche s'est déplacée vers NVIDIA CUDA en raison d'un marketing fort
- Liaison à une seule plateforme
D’un autre côté, la mise en œuvre de la technologie est médiocre. Majorité articles scientifiques et les publications ont été écrites à l'aide de CUDA et adaptées au matériel NVIDIA. L'équipe NVIDIA OptiX n'est pas non plus particulièrement intéressée par la recherche pour d'autres fournisseurs. La société allemande mentalimages, qui a accumulé des décennies d'expérience et de brevets dans ce domaine, appartient désormais également à NVIDIA. Tout cela crée un biais malsain en faveur d’un seul fournisseur, mais le marché reste le marché. Pour nous, tout cela signifiait que toutes les nouvelles techniques de traçage et de rendu GPGPU devaient être à nouveau explorées, mais uniquement sur DirectX et sur le matériel ATI et Intel, ce qui conduisait souvent à des résultats complètement différents, par exemple sur l'architecture VLIW5.
Mise en œuvre
Nous résolvons les problèmesAvant de décrire la mise en œuvre, je vais donner quelques conseils utiles qui nous ont aidé dans le développement :
- Si possible, passez à VisualStudio2012. L'intégration tant attendue avec DirectX, le débogage intégré des shaders et, voilà, la coloration syntaxique HLSL vous fera gagner beaucoup de temps.
- Si VS2012 n'est pas une variante, vous pouvez utiliser les outils Type NVidia Parallel Nsight, mais encore une fois, il existe une liaison à un type de GPU.
- Utilisez le SDK Windows 8.0, c'est votre frère. Même si vous développez sur Windows Vista/ 7 et versions antérieures de VisualStudio, vous disposerez des dernières bibliothèques D3D, y compris le dernier D3DCompiler, qui réduit le temps de compilation des shaders de 2 à 4 fois et fonctionne de manière stable. Il existe un manuel détaillé pour configurer DirectX à partir du SDK Windows 8.0.
- Si vous utilisez toujours D3DX, pensez à y renoncer, ce n'est pas mon frère. Le SDK Windows 8.0 a cessé de le prendre en charge pour des raisons très évidentes.
Rastérisation vs traçage
Malgré le fait que DirectX soit utilisé, il n'est pas question de rastérisation. Le pipeline standard de vertex, Hull, Domain, géométrie et pixel shaders n'est pas utilisé. Il s'agit de sur le traçage des chemins de lumière à l'aide de pixel et de Compute shaders. L'idée de combiner rastérisation + traçage est bien sûr née, mais elle s'est avérée très difficile à mettre en œuvre. La première intersection des rayons peut être remplacée par une rastérisation, mais il est ensuite très difficile de générer des rayons secondaires. Il s'est souvent avéré que les rayons étaient sous la surface et le résultat s'est avéré incorrect. Les gars de Sony Pictures Imageworks, qui développent Arnold Renderer, sont arrivés à la même conclusion.
Rendu
Il existe deux approches principales pour organiser le rendu :
- Tous les calculs ont lieu dans le méga-cœur Programmes GPU, qui est responsable à la fois du traçage et de l’ombrage. Il s'agit de la méthode de rendu la plus rapide. Mais si la scène ne rentre pas dans la mémoire du GPU, soit la scène sera permutée, soit l'application plantera.
- Rendu hors noyau : seule la géométrie de la scène ou une partie de celle-ci est transférée au GPU, ainsi qu'un tampon de rayons pour le traçage, et un traçage de rayons multi-passes est effectué. Le shading se fait soit sur le CPU, soit avec une autre passe sur le GPU. Ces approches ne sont pas connues pour leurs performances étonnantes, mais elles vous permettent de restituer des scènes de taille production.
Nous avons opté pour la première option en utilisant des shaders pour GPGPU, mais avant de rendre quoi que ce soit, nous devons préparer la géométrie et les données de scène, en les plaçant correctement dans la mémoire du GPU.
Les données de scène incluent :
- géométrie (sommets, triangles, normales, coordonnées de texture)
- structure accélératrice (Kd-tree ou nœuds BVH)
- matériaux de surface (type, couleurs, indicateurs de texture, exposants réfléchissants et plus)
- textures matérielles, cartes normales, etc.
- sources d'éclairage (singulières et étendues)
- position et paramètres de la caméra, tels que DOF, FOV, etc.
Il est raisonnable de stocker de petites données qui changent rapidement dans des tampons constants, ce sont les paramètres de la caméra, les sources d'éclairage et les matériaux, s'il n'y en a pas beaucoup et qu'ils tiennent dans un tampon de taille 4096 x float4. À rendu interactif changer la position de la caméra, ajuster les matériaux et la lumière - le plus opération fréquente. Les changements de géométrie se produisent un peu moins fréquemment, mais il n'y a toujours pas suffisamment de mémoire constante pour les accueillir.
Parce que Il y a relativement peu de mémoire dans le GPU, vous devez utiliser des approches intelligentes de son organisation et essayer de regrouper tout ce qui peut être compressé et utiliser la compression des données. Nous plaçons les textures des matériaux dans un atlas de textures multicouches, car... Le nombre d'emplacements de texture GPU est limité. En outre, le GPU dispose de formats de compression de texture intégrés - DXT, qui sont utilisés pour les atlas de textures et peuvent réduire la taille des textures jusqu'à 8 fois.
Emballage des textures dans l'atlas : 
En conséquence, l'emplacement des données en mémoire ressemble à ceci : 
On suppose que les données relatives à la lumière et aux matériaux pourront s'inscrire dans des registres constants. Mais si la scène est suffisamment complexe, les matériaux et les lumières seront placés dans la mémoire globale, où il devrait y avoir suffisamment d'espace pour eux.
Passons au rendu : dans le vertex shader, nous dessinons un quad, de la taille de l'écran, et utilisons la technique de mappage texel à pixel pour qu'une fois rastérisé, chaque pixel du pixel shader ait les coordonnées de texture correctes, et donc , valeurs correctes x et y sur l'écran. 
Ensuite, pour chaque pixel du shader, un algorithme de lancer de rayons est calculé. Cette méthode produit GP Calcul GPU sur les pixel shaders. Cette approche peut ne pas sembler la plus optimale, et il serait plus raisonnable d'utiliser DirectCompute, pour lequel il n'est pas nécessaire de créer de vertex shaders ou de screen quads. Mais de nombreux tests ont montré que DirectCompute est 10 à 15 % plus lent. Dans le problème du traçage de chemin, tous les avantages de l'utilisation de SharedMemory ou de l'utilisation de sursauts de rayons sont rapidement annulés en raison de la nature aléatoire de l'algorithme.
Deux techniques sont utilisées pour le rendu : la vue interactive fonctionne sur un Path Tracing unidirectionnel modifié, et pour le rendu final, le Path Tracing bidirectionnel peut être utilisé, car son framerate n'est pas très interactif dans les scènes complexes. L'échantillonnage selon la méthode Metropolis Light Transport n'est pas encore utilisé, car son efficacité n'a pas encore été justifiée, comme le dit l'un des développeurs de V-Ray sur le forum fermé ChaosGroup :
vlado a posté :
« …Je suis arrivé à la conclusion que le MLT est bien surfait. Il peut être très utile dans certaines situations particulières, mais dans la plupart des scénarios quotidiens, il fonctionne (bien) moins bien qu'un traceur de chemin bien implémenté. En effet, MLT ne peut tirer parti d'aucun type d'ordre d'échantillonnage (par exemple, l'échantillonnage quasi-Monte Carlo, ou la séquence de Schlick que nous utilisons, ou l'échantillonnage N-tours, etc.). Un moteur de rendu MLT doit recourir à des nombres purement aléatoires, ce qui augmente considérablement le bruit pour de nombreuses scènes simples (comme une scène de lucarne ouverte).
Multi‒Cœur. Multi‒Appareil. Nuage.
Notons ce qu'il y a de très bien dans le rendu impartial : il est basé sur la méthode de Monte Carlo, ce qui signifie qu'en cas général Chaque itération de rendu est indépendante de la précédente. C’est ce qui rend cet algorithme attractif pour le calcul sur GPU, systèmes multicœurs et clusters.Pour prendre en charge le matériel des classes DX10 et DX11 et ne pas avoir à tout réécrire pour chaque version, vous devez utiliser DirectX11, qui fonctionne sur le matériel DX10 avec des restrictions mineures. Ayant pris en charge une large classe de matériel et la prédisposition de l'algorithme à la distribution, nous avons réalisé un rendu Multi‒Device dont le principe est très simple : vous devez mettre les mêmes données et shaders dans chaque GPU et collecter simplement le résultat de chaque GPU. dès qu'il est prêt, redémarrer le rendu lorsque l'étape change. L’algorithme permet de répartir le rendu sur un très grand nombre d’appareils. Ce concept est idéal pour le cloud computing. Mais il n’existe pas beaucoup de fournisseurs de GPU cloud, et le temps informatique n’est pas non plus très bon marché.
Avec l'avènement de DirectX11, une merveilleuse technologie est venue à la rescousse : WARP (Windows Advanced Rasterization Platform). WARP Device traduit votre code GPU en code multithread optimisé SSE, vous permettant d'effectuer des calculs GPU sur tous Cœurs de processeur. De plus, absolument n'importe quel CPU : x86, x64 et même ARM ! D'un point de vue programmation, un tel appareil n'est pas différent d'un appareil GPU. C’est sur la base de WARP que le calcul hétérogène est implémenté en C++ AMP. WARP Device est aussi votre frère, utilisez WARP Device. 
Grâce à cette technologie, nous avons pu lancer le rendu GPU dans le cloud CPU. Un peu accès gratuitÀ Windows Azur nous avons reçu via le programme BizSpark. Azure Storage était utilisé pour stocker les données, les données avec la géométrie et les textures de la scène étaient stockées dans des « blobs », les données sur les tâches de rendu, le téléchargement et le téléchargement des scènes étaient dans des files d'attente (files d'attente). Pour assurer fonctionnement stable Trois processus ont été utilisés : un distributeur de tâches (Work Scheduler), un observateur de processus (Process Monitor) et un processus qui télécharge les images rendues (Image Downloader). Work Scheduler est responsable du chargement des données dans les blobs et de la définition des tâches. Process Monitor est responsable du maintien de tous les travailleurs (Worker - nœud informatique Azure) en état de fonctionnement. Si l'un des travailleurs cesse de répondre, une nouvelle instance est initialisée, garantissant ainsi des performances maximales du système. Image Downloader collecte des morceaux rendus de l'image auprès de tous les travailleurs et transfère l'image finie ou intermédiaire au client. Une fois la tâche de rendu terminée, Process Monitor se débarrasse des images de travail afin qu'il n'y ait pas de ressources inutilisées à payer. 
Ce schéma fonctionne bien, et il nous semble que c'est l'avenir du rendu - Pixar effectue déjà le rendu dans le cloud. En règle générale, la tarification du cloud s'applique uniquement au trafic téléchargé, qui consiste en des images rendues ne dépassant pas quelques mégaoctets. La seule chose goulot de cette approche est le canal utilisateur. Si vous devez restituer une animation avec des tailles d'actifs de plusieurs dizaines ou centaines de Go, vous rencontrez des problèmes.
Résultat
Le résultat de tout ce travail a été le plugin RenderBro pour Autodesk 3DS Max, qui, comme prévu, devrait être rendu même sur l'ordinateur de grand-mère et peut utiliser n'importe quelle ressource informatique.Il est actuellement en phase de test alpha fermé. Si vous êtes un passionné de GPU, un artiste 3D, que vous envisagez de construire un cluster ATI/NVIDIA, que vous possédez un tas de GPU et CPU différents, ou toute autre configuration intéressante, faites-le moi savoir, ce sera intéressant de travailler ensemble. J'aimerais vraiment tester le rendu sur quelque chose comme ceci : 
Il existe également une version C++ AMP du rendu à venir, plus sérieuse tests cloud et développer des plugins pour d'autres éditeurs. Rejoignez-nous !
Le rendu GPU dans , et d'autres moteurs de rendu qui utilisent les ressources d'une carte vidéo plutôt que celles d'un processeur, est un vrai délice au début. Le temps de rendu par rapport à, par exemple, a considérablement diminué, vous pouvez évaluer le résultat des changements dans la scène en temps réel, vous pouvez rapidement voir à quoi ressemblera tout dans les rendus finaux, et bien plus encore semblera indiquer la domination incontestable de rendu sur une carte vidéo.
Cependant, tout n’est pas si simple ! Laissons de côté la question de savoir si le rendu GPU est adapté aux exigences de production espèce individuelle graphiques, manque de rendu GPU de production complète et tout ça. Imaginons que vous ayez un petit gang de 3 visualiseurs, que vous réalisez principalement des publicités, et que vous soyez maintenant passé au rendu GPU. Regardons 7 problèmes qui vous attendent :
- Coût élevé des cartes vidéo, mise à l'échelle coûteuse de la capacité
Le plus spécialisé Solutions GPU suggèrent que l'ajout de cartes vidéo coûte moins cher que l'achat ordinateur complet, mais uniquement lors de l'achat d'armoires de serveurs et de systèmes spéciaux pour le fonctionnement grande quantité cartes vidéo De telles solutions en elles-mêmes ne sont pas bon marché et nécessitent certaines compétences. Mais imaginons que nous ayons emprunté le chemin de l'achat ordinateurs standards et y installer 2-3-4 cartes vidéo. Comparez le coût d'une future mise à niveau du processeur et d'une mise à niveau de ces 2-3-4 GPU.
2. Peu d'influence des cartes vidéo sympas sur l'ensemble du système
Contrairement à une mise à niveau du processeur, qui affectera le fonctionnement de toutes les applications, les cartes vidéo n'auront pour effet que de réduire le temps de rendu. Leur présence n'affectera en aucun cas le fonctionnement du système d'exploitation ou des éventuelles applications graphiques 3D. Sauf peut-être pour les jeux. Mais vous ne jouez pas sur votre ordinateur de travail, n'est-ce pas ?)
En termes simples, lorsque vous dépensez de l'argent sur un GPU à des fins professionnelles, cela vous offre des avantages très limités et spécifiques.
3. Bruit constant et génération de chaleur
Le refroidissement de presque toutes les cartes vidéo est beaucoup plus bruyant que le fonctionnement Refroidissement du processeur. Ce qui est encore plus important, c'est que emploi permanent 2-3 cartes vidéo créent rapidement une température insupportable dans la pièce.
4. Problèmes de mise à l'échelle
Si vous possédez plusieurs machines GPU, tôt ou tard la question de l'achat de licences supplémentaires se pose et il peut y avoir des problèmes de compatibilité avec les cartes vidéo divers fabricants Et différents modèles. À mesure que la flotte se met à jour, un choc entre les générations de cartes vidéo est inévitable. Rappelez-vous que si un système possède, par exemple, une carte vidéo avec 8 Go de mémoire et 12 Go, la mémoire sera limitée à une valeur inférieure.
Une simple mise à jour du pilote peut tout faire planter. Les cartes vidéo de n'importe quel système sont la principale source de blocages et de plantages. Tout problème de mise à jour des pilotes, de leur compatibilité, bugs et autres plaisirs engendrera certainement des problèmes de rendu ! Inutile de dire que de tels problèmes ne surviennent pas lors du rendu sur un processeur.
6. Mémoire limitée
Actuellement, la GTX 1080Ti ne dispose que de 12 Go de mémoire, qui ne peuvent pas être augmentés en insérant une barre mémoire comme dans ordinateurs ordinaires. Et cela ne s'additionne pas lors de l'installation de plusieurs cartes. Si, par exemple, vous installez 3 de ces cartes, alors 12 Go seront disponibles pour les scènes. Si la mémoire disponible sur le rendu est dépassée, tout plante tout simplement. Il n'y a pas d'options comme sur le CPU utilisant un fichier d'échange, ce qui, même s'il ralentit le rendu, le rend néanmoins possible.
7. Cercle limité PAR
Rendu GPU pris en charge quantité limitée applications graphiques et les rendus, ce qui impose ses propres limites.
En conclusion, je noterai. que malgré les inconvénients du rendu GPU, il présente également des avantages incontestables qui compensent largement les inconvénients existants.
Contrôler le temps de rendu est une chose avec laquelle chaque studio doit lutter. En tant qu'artistes, nous voulons être limités uniquement par notre imagination, et non par la puissance de l'ordinateur dont nous disposons. Chez Pixelary, nous connaissons très bien les caractéristiques de performance de Cycles. Nous avons lancé ce blog dans le but de partager nos connaissances. Alors voyons ce que ça donne meilleur rapport performance/coût lors de la création de pixels.
Le GPU est rapide, bon marché et évolutif
400 dollars carte vidéo de jeu, comme GTX 1070 ou Radeon RX580 plus rapide que 22 renseignements nucléaires Xeon 2699v4 (3 500 $) pour la plupart des tâches de rendu. Si l’on considère uniquement le prix du matériel, le GPU est clairement le gagnant. La valeur du GPU augmente encore plus, car nous pouvons facilement installer 4 cartes vidéo dans une unité centrale, obtenant ainsi une vitesse de rendu multipliée par 4, tandis que systèmes multiprocesseurs valent TRÈS cher. Mais les GPU ont un inconvénient...
Limites de mémoire GPU
Pour effectuer le rendu sur le GPU, Cycles doit placer toutes les données de scène dans la mémoire de la carte vidéo. Si la scène ne convient pas, le rendu sera tout simplement impossible. La plupart des GPU grand public disposent aujourd’hui de 8 Go de mémoire. Cela signifie que vous ne pouvez adapter que 32 textures uniques à une résolution de 8K avant que la mémoire ne soit complètement pleine. Ce n'est pas beaucoup de texture. Il existe des GPU avec plus de mémoire, mais leurs prix sont souvent astronomiques, ce qui rend le rendu GPU aussi cher que le rendu CPU. D'un autre côté, même si le rendu CPU n'utilise pas moins de mémoire, BÉLIER beaucoup moins cher. 32 Go de RAM peuvent être achetés à un prix très raisonnable.
Consommation d'énergie
Pour les studios produisant un grand nombre de rendus, la consommation électrique est un autre aspect à prendre en compte. Étonnamment, malgré grande différence En termes de prix entre CPU et GPU, les performances par watt sont étonnamment similaires pour les appareils dotés de un grand nombre noyaux. Les GTX 1070 et Xeon 2699v4 ont une consommation électrique maximale d'environ 150 W et ont des performances à peu près identiques. Ainsi, quel que soit l'appareil que vous utilisez, le matériel de la même génération devrait consommer à peu près la même quantité d'énergie. Cependant, les processeurs avec un faible nombre de cœurs et haute fréquence, comme l'Intel 7700k, ont tendance à consommer plus d'énergie que processeurs multicœurs avec une vitesse d'horloge faible.
Ensemble de fonctionnalités
Bon, assez parlé matériel. Nous devons également comparer les différences de capacités entre le rendu CPU et GPU. Quant à Blender 2.78c, le rendu GPU et le rendu CPU sont pratiquement au même niveau. Il n’existe qu’un petit ensemble de fonctionnalités qui ne sont pas prises en charge par le GPU, et la plus grande fonctionnalité manquante est l’Open Shading Language. Mais, à moins que vous n'envisagiez d'écrire vos propres shaders, le GPU est aussi performant que le CPU.
Systèmes d'exploitation
Certaines personnes disent que c'est certain systèmes d'exploitation fournir jusqu'à 20 % d'accélération du rendu. Ce serait génial si c'était vrai, non ? Nous aimerions aller au fond de cette question. Par conséquent, nous examinerons cette affirmation plus tard et publierons nos conclusions.
Bonjour, chers lecteurs.
Permettez-moi de faire une réserve tout de suite : cet article n'est pas une revue détaillée, mais a uniquement pour but de aperçu général initiez les débutants au rendu RT à l'aide d'une carte vidéo.
rendus biaisés et impartiaux
Sur la base du principe de fonctionnement, tous les rendus peuvent être divisés en 2 grands groupes.
Biaisé- ce sont des moteurs de rendu adaptatifs qui calculent tout effets physiques un par un, puis connectez-les selon les paramètres, accessible à l'utilisateur. L'adaptabilité s'exprime par la présence d'un grand nombre de paramètres qui affectent la qualité de l'image finale.
Le moteur de rendu biaisé créera d’abord une carte lumineuse de tout l’espace pour lui-même, puis la « superposera » sur la géométrie afin de comprendre quelles zones doivent être calculées avec précision et lesquelles ne le sont pas. Disons qu’il « voit » que la zone située dans le coin de la pièce n’est pratiquement pas éclairée. Il vérifie les paramètres et réduit la qualité du traitement de cette zone au minimum spécifié par l'utilisateur - pourquoi effectuer des calculs complexes si les objets se trouvent dans de fortes ombres et hautes lumières, les reflets, etc. ne seront en aucun cas clairement visibles sur eux ?
Impartial- ce sont les soi-disant « moteurs physiquement corrects ». Ils prennent la scène entière et commencent à la calculer avec des « paramètres infinis ». En pratique, cela se passe ainsi : au début, l'image entière a une qualité épouvantable et un bruit épouvantable. Au fur et à mesure que le rendu progresse, le bruit commence à disparaître et la qualité de l'ensemble de l'image commence à s'améliorer.
De quel type est le moteur V-Ray populaire ?
V-Ray peut fonctionner dans les deux modes. La commutation se fait comme ceci : F10-Common-Assign Render (tout en bas)
- VRay Adv - Biais
- VRay RT - Impartial
Comment tout cela s'applique-t-il aux cartes vidéo ?
Le rendu sur une carte vidéo (rendu GPU) n’est possible qu’en « mode » impartial. D’où le premier point controversé.
D'une part dans cartes vidéo modernes beaucoup plus de cœurs que dans processeurs modernes. Les marketeurs aiment souvent le mentionner =)
Par exemple, le 660 Ti, selon la spécification, possède 1344 cœurs. Et le processeur est 4 physiques et 8 virtuels.
D’un autre côté, ces noyaux sont comme des soldats d’un bataillon de construction, prêts à travailler à la pelle « d’ici à demain ». Ils ne savent pas comment penser et optimiser leur travail, donc le volume de ce travail augmente de manière disproportionnée. Les spécialistes du marketing restent silencieux à ce sujet.
Quel rendu est le meilleur ?
Impartial, c'est-à-dire Le rendu GPU vous permet d'obtenir une image plus physiquement correcte, mais prend beaucoup plus de temps, même sur des cartes vidéo puissantes.
De plus, lorsqu’on tente d’estimer vraie différence la complexité surgit avec le temps - À la base, le rendu impartial est infini,il peut compter l'image pour toujours, en l'améliorant constamment.La seule question est de savoir quand une personne cessera de remarquer la différence et, comme vous le comprenez, cette ligne n'a pas de limites claires.
Le rendu sur le processeur (CPU) permet d'obtenir une image de haute qualité beaucoup plus rapidement avec un niveau de photoréalisme tout à fait acceptable. Cependant, il convient de considérer que la qualité de l'image restituée par un processeur dépend fortement de la capacité de configuration du moteur de rendu.
Que doit choisir un débutant ?
Pour un débutant, inutile de prêter attention au GPU.
- C'est le rendu le plus long. Il n'est en aucun cas adapté au processus d'apprentissage, qui implique la création d'un grand nombre d'images approximatives ;
- L'utilisation pratique des GPU n'est pas justifiée dans toutes les tâches et implique l'utilisation uniquement de cartes vidéo coûteuses. Si vous êtes débutant, de telles tâches n'apparaîtront pas de sitôt.