Si la route d'ici à Blender 3.0 va encore être longue, le célèbre outil de création et de rendu 3D continue de faire évoluer sa branche 2.9. Des améliorations pour OptiX et le support de la partie graphique Xe des processeurs Tiger Lake d'Intel via OpenCL arrivent. Voici nos premiers résultats.
Blender est un outil open source au développement assez ouvert et organisé. On peut ainsi voir par avance les fonctionnalités attendues pour les prochaines versions, les tester via des builds officielles. Actuellement, c'est la 2.92 qui est en phase de bêta, avec le support de NVIDIA OptiX pour du rendu hybride (CPU/GPU) par exemple.
Mais nous attendions avec impatience une autre nouveauté du moteur Cycle : le support des processeurs Tiger Lake d'Intel et leur partie graphique exploitant la nouvelle architecture Xe pour un rendu via OpenCL. L'occasion d'enfin tester la bête avec une application concrète, pouvant nous servir de base de comparaison.
Nous avons justement un Razer Blade Stealth 13 sous la main, exploitant le Core i7-1165G7 et une GeForce GTX 1650 Ti. Nous en avons profité pour effectuer de premiers essais avant la publication de notre test complet.
Blender 2.92 bêta se récupère sur la page consacrée aux versions expérimentales de l'outil. Une fois lancée, elle fonctionne comme n'importe quelle autre. Seule différence visible pour ce qui concerne le mode de rendu avec la 2.91 actuelle : le Core i7-1165G7 et sa partie graphique Iris Xe y sont tous deux référencés :
Pour nos tests nous utilisons la classique scène de test bmw27, qui est proposée dans une version optimisée pour un calcul sur CPU et sur GPU. Dans le second cas, la décomposition de l'image se fait en un nombre réduit de tuiles, plus grosses (512 pixels de côté contre 32 pixels de côté). Nous avons commencé avec un test CPU :
Blender 2.92 - bmw27 CPU :
- Ryzen 7 4800U : 4min47s
- Core i7-1165G7 : 8min23s
Ici nous opposons notre PC portable Razer au processeur Ryzen Mobile de série U le plus performant de la gamme actuelle d'AMD : le 4800U. Nous l'utilisons tel qu'intégré dans le mini PC PN50 d'ASUS. Comme on pouvait s'y attendre, avec deux fois plus de cœurs, il est... deux fois plus rapide. Ce, malgré les différences de fréquence.
Voyons maintenant ce qu'il en est avec les deux parties graphiques intégrées, opposées à la GeForce GTX 1650 Ti intégrée au Blade Stealth 13 de Razer. Pour rappel, celui-ci est certifié Max-Q.
Blender 2.92 - bmw27 GPU :
- Ryzen 7 4800U - OpenCL - IGP : 12min04s
- Core i7-1165G7 - OpenCL - IGP : 7min57s
- GeForce GTX 1650 Ti - OptiX - GPU : 2min19s
Malgré l'absence d'accélération matérielle du ray tracing (réservée aux GeForce RTX), le GPU de NVIDIA est le plus performant, de loin. Il va presque quatre fois plus vite que la partie graphique Xe, six fois par rapport à celle du 4800U.
Cette dernière n'est d'ailleurs pas très intéressante à utiliser puisqu'elle est bien moins rapide que le processeur auquel elle est intégrée, qui va presque trois fois plus vite. Chez Intel, c'est légèrement différent puisque l'IGP Xe permet de grappiller près d'une trentaine de secondes. Mais avec un désavantage : le rendu sur IGP/GPU nécessite la compilation d'un noyau spécifique avant le premier rendu, une étape assez longue ici. Autant s'en passer, donc.
Et si l'on utilise l'entièreté de la puce ? Nous avons activé OpenCL dans Blender 2.92 avec nos couples CPU/IGP, puis avons fait de même avec OptiX et le duo Core i7-1165G7 / GeForce GTX 1650 Ti :
- Ryzen 7 4800U - OpenCL - IGP + CPU : 6min37s
- Core i7-1165G7 - OpenCL - IGP + CPU : 6min13s
- GeForce GTX 1650 Ti - OptiX - GPU + CPU : 2min00
Cette future version de Blender semble apprécier, puisque même dans le dernier cas, on arrive à gagner 19 secondes (13,7 %). Pour le Core i7-1165G7 et sa partie graphique Xe, le temps de rendu est réduit de 22 %, passant (de peu) devant le Ryzen 7 4800U dans ce test. Ce dernier garde néanmoins l'avantage avec son score CPU.
Commentaires (28)
#1
Intéressant - mais dommage pour moi, j’ai commandé un Intel 6C/6T en 35W pour faire (entre autres) mes rendus blender…
Je trouve que le SMT AMD est plus performant que celui d’Intel. Quand je compare un 8250U à mon Ryzen 3400GE, le gain en montant en threads est quasi linéaire sur le Ryzen (en gros 7,5x la perf d’un CPU), sur le Intel les 8 threads ressemblent plutôt à 6/7x la perf d’origine.
Bon, après, le Ryzen est sur une enveloppe thermique de 35W, 15W pour l’Intel. De même pour la cache, supérieure sur le ryzen il me semble. Inutile de comparer je pense avec mon 4702MQ, il est un peu vieillot maintenant (quoique les résultats sont proches du 8250U)
#2
Oui, il ne faut pas confondre l’efficacité du SMT et l’impact de la limite en TDP sur un CPU.
#3
C’est bien pour cela que je ne publie pas de tests: ils sont très persos… Et très vite on ne sait plus ce qu’on mesure dès que ça a tourné…
Mais je communique quand même mes impressions: le SMT d’AMD me semble vraiment très réussi. Vu le temps qu’a mis Intel pour en avoir un plus cohérent/prévisible…
Et je ne dis pourtant pas qu’intel sont des bleus
#4
Tu as tout dit. Ton AMD peut chauffer 2,3 fois plus, heureusement qu’il fonctionne mieux.
En plus, tu compares un processeur sorti en 2020 contre un sorti fin 2017.
Si tu veux comparer, prends des H (45W avec TDP diminuable).
Le SMT d’Intel est très bon. Ce qui a piné tes tests, c’est la montée en chauffe qui, a 15W, est extrêmement rapide sur tout les coeurs.
Personnellement, je me fie à ce site, et je pense avoir mis les bon processeurs pour comparer
https://www.cpubenchmark.net/compare/Intel-i5-8250U-vs-AMD-Ryzen-5-3400GE-vs-Intel-i7-4702MQ-vs-Intel-i5-8300H-vs-Intel-i5-10300H/3042vs3690vs1939vs3254vs3646
#5
Pour mesurer l’efficacité du SMT, le plus dur, c’est d’éviter toute contribution des changements de fréquences.
Dans Windows, quand on modifie la “Gestion d’alimentation du processeur” dans “option d’alimentation” et qu’on ajuste “l’état maximal” à autre chose que 100% (genre à 99%), il me semble que les turbos ne fonctionnent pas. Donc en multithread, on doit se retrouver à la même fréquence max qu’en mono pour chaque coeur. A confirmer.
Sinon, il faut verrouiller à la main une fréquence dans le BIOS (dur dur pour les portables), et comparer mono/multithread (à défaut, mettre un pourcentage dans l’état maximal, pour bloquer à une fréquence “basse”). Sur mon vieux i7 980, vu qu’il est OC c’est donc la même fréquence pour tous les coeurs : l’HT apporte 30% de pèche, mais c’est pour le test de CPU-Z (v 17.x)
#6
Fin du HS, merci
#7
Vous n’avez pas encore de Cezanne sous la main ? Oui je sais le GPU ne change pas grand chose dans Cezanne
#8
J’ai ajouté le 8259U (28W) qui est une belle bête et qu’on trouve dans les NUC 8i5 - sur ce bench, il bat le 8300H.
Je m’étais souvent demandé, surtout suite à une mauvaise expérience avec un Core-m3 en 3.5W, si un iGPU intégré peut être intéressant en OpenCL pour travailler en même temps que le CPU - où si tout allait se limiter à cause de la chauffe. Justement je me posait la question avec le 8259U dont le Iris Graphics n’est pas très performant, mais sur certains calcul peut faire 1⁄2 coeur voire 1 coeur supplémentaire.
Le mix semble complexe à évaluer à la louche - comme le montre l’article: on peut décélérer facilement.
On parle assez peu du Xe, surtout vu les articles qu’on a vu sur les APU AMD qui n’ont rien de phénoménal: sur portable il est difficile de jouer avec quand même. Les Xe ont souvent une bonne longueur d’avance, et sont assez polyvalents pour permettre le GPGPU “d’appoint”.
Mais est-ce que cela implique une chauffe ou une conso excessive? Le compromis de tout faire via l’IGP (donc temps de rendu intermédiaire) met-il en évidence une conso/ un échauffement moindre face à la solution CPU (au vu des “pics” qui semblent assez violents sur les I5/I7 des séries 1xxx)
#9
Le TDP est le même pour CPU/IGP, du coup, cela ne change rien sur la chauffe/conso. Par contre ton GPU peut être plus efficace pour certains calcul. L’utilité du calcul hybride dépendra aussi de l’application, toute le gèrent pas, ce n’est pas forcément toujours efficace. Ce qui manque à Xe ici, c’est une accélération du ray tracing par exemple, que l’on trouve pourtant déjà sur des parties graphiques intégrées chez ARM (notamment chez Apple depuis quelques générations).
#10
Sérieusement, vu la maturité de ce moteur (fonctionnalités, conformité du rendu, …) , , il faudrait peut-être sortir Optix des benchs et se rabattre sur cuda. C’est un peu facile d’être le plus rapide avec une large marge si on ne fait pas tous les calculs et qu’on ne supporte pas toutes les fonctions. Alors certes il a du potentiel, mais pour le moment c’est plus une démo qu’une solution aboutie.
#11
Se rabattre su CUDA, ça veut dire que ça utile que pour les GPU Nvidia
#12
Je ne pense pas que ça marche pour blender, mais je l’ai utilisé avec succès pour utiliser une librairie de réseaux de neurones:
ZLUDA
Ca reste un peu pathétique que ce soit niveau perfs (j’étais sur du UHD, pas du XE) ou niveau du bazar pour mettre en place (surtout avec des librairies récupérées par python…)
#13
Tu n’as peut-être pas compris le contexte… Optix est aussi une solution purement Nvidia, mais vu les simplifications que Optix fait, je proposais de ne pas utiliser Optix comme api de référence sur nvidia justement parceque ce n’est pas équitable pour d’autres api qui font une implémentation plus complètes.
Et tant qu’à faire, utiliser une scène de référence un peu plus complète, car bmw27 n’est plus vraiment représentatif question complexité, mémoire, …
#14
L’idée c’est de voir le niveau des ordres de grandeur sur la version actuelle (qui reste une alpha, on aura le temps de compléter d’ici la version finale). Même si tu utilises CUDA plutôt qu’OptiX, tu restes largement sous de l’IGP (et c’est assez logique). Il ne faut pas oublier que c’est ici des puces graphiques intégrées, prendre une scène de référence qui met 1h30 a rendre, c’est pas franchement le plus simple pour publier un test avec de nombreux résultats ;)
#15
Et si on veut faire du rendu complexe, on investi sur autre chose qu’un ordi portable :)
Surtout que comme d’habitude, avec l’échauffement la performance sur une durée plus longue dépend du refroidissement de l’ordi (cf des portables DELL qui sont à peine plus voire moins performants en i7 qu’en i5)
Mais je rejoins l’avis sur Optix: autant le rendu Cuda est bien connu et est une référence pour ceux qui font du blender, autant Optix ne peut être cité que “pour info”, car s’il est incomplet, ses performances ne sont peut-être pas représentatives.
#16
Pas forcément tu peux avoir à faire du rendu en mobilité, mais dans le cas de besoins complexes sur des temps de rendu court, tu prends une machine adaptée.
#17
Si vraiment tu fais du rendu en mobilité, la GTX/RTX est encore de mise si on regarde les résultats.
LA GTX1650, c’est une version de portable?
Ce que je retiens du test, c’est que le intel Xe place la barre “haute” pour l’intégré, sauf que le Xe n’est pas encore généralisé sur la gamme intel et que là on parle du Xe sur le haut de gamme intel (G7, il me semble que c’est le top).
Bref, que ce soit AMD ou Intel sur des configs à 1000-1200€, ça ne gomme pas l’intérêt de la CG pour le GPGPU.
#18
Personne ne l’a prétendu
#19
Hmm, en passant, je viens de faire tourner le benchmark en question, je suis à 7.95 secondes (cuda gpu seul)… est-ce que les chiffres plus haut n’inclueraient pas par hazard les phases de recompilation du kernel cuda? Par comparaison, ça semble effroyablement long, non?
#20
Non, mais si tu le fais avec une RTX 3090 c’est normal ;) Sinon, tu as peut être un souci dans ton relevé
#21
c’est une 3080 un peu OC … c’est vrai que ma GTX 980 faisait ça genre en presque deux minutes et demi… presque un facteur 19
#22
Oui et encore si tu es en CUDA c’est hors optimisation, Optix peut accélérer la phase de rendu et aussi le denoiser, m’enfin avec un départ à 8 secondes tu vas pas grailler grand chose
#23
J’utilisais le denoiser optix déjà avec la 980 (faut dire que les perfs incitaient à pas faire trop d’échantillons et à plutôt pousser la réduction de bruit). Optix pour le rendu me laisse malheureusement souvent tomber sur des shaders un peu complexes (qui ne marchent juste pas) et fait parfois du clamping mal venu sur les réflexions/diffusions (conférant un aspect plastoc là où on voudrait plus de dynamique et de détails dans certaines réflexions).
#24
Oui ça reste le souci, vu qu’il est encore au stade expérimental/incomplet dans ses fonctionnalités. Pour Optix/980 tu parles via Blender (parce que son intégration native est récente, tout comme l’OID d’Intel) ?
#25
Oui, c’était avec blender 2.90 (septembre 2020) que c’est devenu dispo sur la 980, je ne suis passé à la RTX qu’en décembre donc j’ai encore pu tester sur la 980.
#26
je fais 50 seconde à ce benchmark !!!
https://opendata.blender.org/benchmarks/ab44430a-f107-4a38-8882-27e31a2ada99/
#27
Une 3060 Ti fait 19 secondes pour référence
#28
par contre j’ai du merde dans la configuration de mon BIOS de carte mère, ça me le fait de temps à autre, mais là maintenant au benchmark complet je fais 13 minutes et 52 secondes:
https://opendata.blender.org/benchmarks/64f0da36-24d4-495e-8af6-9073d5f5c98d/
alors qu’en septembre 2020 je faisais 12 minutes et 50 secondes( dont 48,51 secondes au teste BMW27) au même benchmark avec la même version de Blender:
https://opendata.blender.org/benchmarks/c4d3da24-8ad8-4048-8c86-d6a002a41f55/
faut que je mettre les bons paramètres dans le SETUP de Bios, truc chiant à chaque mise à jour du BIOS de la carte mère il refait un CCMOS, obliger de tout remettre a la main.