AMD et les développeurs de Blender ont adapté le nouveau moteur de rendu de Blender 3.0, Cycles-X, aux Radeon récentes via HIP qui prend le relais d'OpenCL. De quoi permettre une simplification du code au passage.
Comme nous l'évoquions fin septembre, Blender 3.0 est une version très attendue, notamment du fait de l'intégration de son moteur de rendu renouvelé Cycles-X. Celui-ci a décidé de tirer un trait sur OpenCL, se focalisant sur des solutions plus spécialisées et performantes comme NVIDIA OptiX, ce qui laissait AMD et Intel sur le carreau.
On s'attendait à ce qu'une solution soit trouvée d'ici la publication de la version finale le 3 décembre. C'est le cas pour AMD qui annonce dans un billet de blog le support de ses cartes par les dernières versions bêta de Blender 3.0.
Dans notre précédent article, nous notions l'existence d'une proposition d'intégration de HIP (Heterogeneous-Compute Interface for Portability), qui est pour rappel la solution d'AMD pour exécuter du code C++ sur un GPU (GeForce ou Radeon), à la manière de CUDA chez NVIDIA. C'est ce qui a été utilisé par les développeurs de Blender.
AMD indique que HIP leur permet « d'écrire un ensemble de kernels de rendu et de les exécuter sur différents composants » avec l'intérêt d'une migration aisée depuis un code CUDA, puisqu'il a été pensé dans ce sens.
L'objectif était en effet de ne plus avoir un code différent pour un rendu CPU, ou sur GPU via OpenCL et CUDA, mais une solution unique et efficace pour tous, avec des alternatives pour d'éventuelles accélérations matérielles comme OptiX (AMD proposant pour sa part un moteur spécifique à ses Radeon, ProRender).
Mauvaise nouvelle néanmoins, pour le moment, Cycles X n'est exploitable que via l'architecture RDNA (Navi, RX 5000 et RX 6000). Son support n'est pour le moment certifié que pour RDNA 2 (Navi 2x, RX 6000) et la Radeon Pro W6800. Un pilote beta (21.40) spécifique a été mis en ligne, uniquement pour Windows.
Commentaires (3)
#1
Bon en fait ça tombe bien, j’avais l’intention de paseer à du tout AMD pour ma prochaine machine, mais vu l’état du marché, c’est pas pour demain…
#2
OpenCL résonne/résonnait comme une fantastique idée, mais ce genre de nouvelle semble en sonner le glas.
Le problème de la séparation des tâches en CPU & GPU via OpenCL est-il un problème de conception ou d’utilisation ?
En tout état de cause, se détourner d’un standard de Khronos Group pour retourner vers des implémentations d’API particulières au vendeur du matériel présent dans la machine utilisée (comme c’était le cas avant) est une mauvaise nouvelle, à de multiples titres.
#3
Parce que C(++) ce n’est pas du standard ? OpenCL a surtout été lancé pour tenter de faire concurrence à CUDA (dont il est un dérivé pour rappel au départ) sans que personne ne s’y investisse vraiment. Il n’a jamais massivement été utilisé, aussi pour cette raison.
Maintenant, il y a des besoins concrets et donc des solutions (efficaces) à trouver. Parce qu’il faut forcément que le GPU puisse comprendre le code C(++) et qu’il soit adapté, donc une couche intermédiaire. La solution d’AMD est non limitée à ses propres GPU et open source, quel est donc le problème sur le fond ?