Plus de RAM pour Resolve?

Bonjour à tous!

Je me posais la question d'upgradé un peu mon iMac en passant de 16 à 32Gb de RAM, mais je voulais savoir si ça peut avoir un réel impact sur Resolve 11? Je sais que ce qui est vraiment important c'est la CG, mais est-ce que plus de RAM permettrait d'être plus fluide?
J'ai pas vraiment réussi à trouver de réponse à ce propos..
Donc merci d'avance.

 

Hello,
ça ne peut pas ne pas être utile du tout...
Toutefois, le logiciel étant correctement "multithreadé" (les tâches sont segmentées et envoyées également à chaque coeur), je ne sais, pas si tu verras un gain énorme dans Resolve, puisqu'à partir du moment où tu as 2 Go de Ram par coeur de la machine, tu as déjà l'essentiel requis.
Évidemment, d'autres softs plus axés CPU en tireront profit par contre.

Si c'est spécifiquement pour Resolve, je ne pense pas que ce sera "plus fluide".
Plus de mémoire du GPU par contre, ça c'est une bonne idée, par exemple passer de 2Go de mémoire de carte graphique à 4 ou 6.
M'enfin j'imagine que tu as déjà une GTX 780*, et que comme c'est un iMac tu vas pas avoir beaucoup de choix d'upgrade.
*si c'est pas le cas, mets déjà ça, ton budget sera mieux utilisé si c'est pour Resolve que tu le fais.

 

Hello,

Non ça ne sera pas que pour Resolve, et je sais que notamment After Effect sera bien content de pouvoir compter sur cet extra en RAM, même si c'est clair je joue la prévoyance car j'ai pas vraiment eu de projet encore ou j'ai été titillé les limites de ma machine..

Oui j'ai bien la GTX780m, donc déjà comme tu dis pour Resolve c'est pas mal. Je pense que pour gagner en fluidité ça serait surtout de bosser direct via SSD/Thunderbolt j'imagine? Quand je bosse sur mes disques en usb3 ça galère un peu

 

Pour gagner en fluidité (autre qu'une 2ème carte graphique), oui, peut-être qu'un accès disque jouerait un bon rôle. Sans particulièrement en faire un conseil, j'ai un raid0 de SSD pour les rushes.
Et je n'ai pas de iMac justement à cause de ce genre de cas de figure de manque de possibilités d'upgrade matériel (bus PCIe, GPU, disques internes, ...)

 

Tu parles de deuxième carte graphique, et ça me fait pensé, qu'à l'époque ou un ordinateur ne me servait qu'à jouer, j'avais regardé pour avoir une deuxième cg en externe, sur le même principe que la RED rocket en gros, je ne pense pas que ça s'utilise dans le milieux pro mais je vais essayé de regardé quand même.

Le choix de l'iMac était vraiment une question de budget, j'aurais pu me permettre le nouveau macpro, qui la question upgrade se positionne mieux que l'imac, mais sans pouvoir me permettre l'écran qu'il mériterait etc..
Mais bon pour l'instant je suis plus que satisfait de ma machine, quand j'arriverai sur des prod vraiment lourdes, on verra s'il serra temps de changer de config

 

Je ne critique en rien le choix iMac, je voulais juste dire que pour certaines utilisations suggérant des upgrades matériel, c'est restreint*.

Si si, dans le milieu pro, on utilise aussi des CG externes, mais les solutions sont couteuses (voir "cubix expander" par ex.). Lorsque 2 CG sont vues dans Resolve, celle sur laquelle est branchée le moniteur sert à l'affichage GUI, tandis que l'autre sert à calculer les gros boulots (avec moyens d'appeler la 2ème en renfort évidemment).

*pour te donner une idée, même sur un MacPro 2008-12 où il y a de la place, le pb majeur est l'alimentation, puisque les CG demandent généralement 2 connecteurs chncune, alors que par défaut il y en a... 2 en tout. Peu font la bidouille rébarbative d'enlever un DD interne pour transformer sa connectique alim (genre molex etc.) à destination d'une 2ème CG.

Donc finalement, 2 CG internes, c'est exclu sur iMac mais compliqué sur MacPro aussi (c'est sur le reste que c'est pratique).

Bref, tout ça pour dire que pour Resolve, au même titre que les appli dites GPGPU, c'est vraiment la carte graphique qui compte, et son nombre de cuda cores si l'on utilise une CG Nvidia.
Il reste la possibilité de suivre l'actu et de voir s'il devient possible de mettre des carte graphique avec 2 GPU (genre GTX 690), mais c'est un budget, et sur iMac ça m'étonnerait fort.

 

J'ai été voir les solution de Cubix, c'est un peu ce à quoi je m'attendait, pas du tout fait pour des indé comme moi

Ouais c'est les cuda cores qui priment pour ce soft je l'ai vite compris, mais bon je ne pense pas arriver au bout de ma cg pour l'instant comme je le disais, donc tant mieux, j'espère juste que ça ne deviennent pas LE point limitant dans ma config dans les prochaines années...

 

Pas forcément maintenant avec des cartes récente et sous Mac faire tourner Resolve en Open CL ça marche aussi très bien, je suis passé depuis déjà un moment des cartes Cuda des Quadro 4000 à une machine puissante certes mais en utilisant l'Open CL et ça marche très fort chez moi.

Pour la machine regardes les spécificités fournit par Blackmagic sur leur site, je trouve que c'est une chance qu'un développeur se vende de cette doc pour un logiciel donc autant l'utiliser.

Mais en effet selon ce que tu as déjà en RAM en rajouter peut ne servire à rien c'est surtout la mémoire sur la carte vidéo et avec l'Imac cette augmentation de puissance doit être faite à l'achat.

Après utiliser plusieurs disques pour Resolve, là, c'est clairement un plus. Idéalement un disque dans l'Imac pour le logiciel, un disque externe pour les medias, et un autre disque pour les sauvegardes et enregistrements. Ou deux disques; l'interne pour le soft et les sauvegardes et un externe pour les médias. Ça permet de lire en même temps le media, faire tourner le soft et enregistrer les données sans faire toutes ces requêtes sur le même disque. Par contre des disques rapide ou sinon on ne va rien gagner.

 

Il faut se faire une raison: à terme l'OpenCL va être privilégié par les développeurs au détriment de CUDA.
Pour les softs utilisant les SDK des fabricants de caméra c'est important car ces SDK sont sous OpenCL et, malheureusement cette librairie est piteusement gérée par CUDA sur OSX, d'où des pertes de performances.
Si les nouveau Mac "Trash can" Pro on des D500 ou 700 (ATI) ce n'est pas un hasard. Avec un octocore et 2 x D700 un MacPro peut maintenant decoder le l'EPIC 5K en full size et en temps réel. Pas besoin de chassis Cubix avec une RR.

 

Sources ?
Non pas que je comprenne pas, mais je crois qu'il faut rester un peu plus modéré lorsqu'on évoque un pronostic sur une large tendance...
Par ailleurs, OpenCL n'est pas sensé "être géré par CUDA" mais par OSX directement, et c'est le système qui ne met pas rapidement à jour ses lib (tout comme OpenGL), bien qu'il le fasse plus rapidement depuis le dernier MacPro et un Mavericks optimisé pour Mavericks + double GPU AMD, donc OpenCL.

Donc pour l'instant, sur une même machine où l'on pourrait changer de CG facilement pour tester (ex: un MacPro legacy - soit 2008 à 2012), mettons une bonne AMD et une bonne nVidia sous Resolve*
[*BMD a mis à jour ses lib et la propo de switch dans les pref a du sens] :
il vaudra mieux une bonne nVidia avec CUDA choisi des les pref qu'une bonne AMD avec OpenCL... Là, maintenant, dans un soft proposant la gestion équivalente des 2.

Donc après, la politique marketing + MAJ des lib (rappelons le : par Apple direct pour openCL et par nVidia pour cuda) + MAJ des drivers + politique tournée vers les dev etc font que la tendance se précise... Pour l'heure, moi je n'ai pas de préféré, mais CUDA a de beaux jours quand même et nVidia a des panneaux de pref système pour MAJ lib + drivers assez souvent mis a jour (et OpenCL, on voit quoi ?).
Donc voulià, je voulais juste mettre un bémol sur une affirmation qui sonne un peu comme (c'est une analogie blague hein) celle d'un barbu libriste qui explique depuis 20 ans que son Linux va dépasser 1,5% de PDM sur desktop grand public .
Je crois qu'il faut attendre un peu et ne pas sous-estimer les actions de propagande que pourraient faire nVidia pour rester dans la course.

 

Je ne suis pas un spécialiste MAC, mais je pense qu'il n'y a aucune différence sur ce point avec le fonctionnement sur PC :

OpenCL et Cuda sont des interfaces de programmation (API) appelables par des applications (les logiciels de montage) pour utiliser les moteurs de calcul massivement parallèles disponibles sur la cartes graphiques AMD et Nvidia.

Ces API sont fournis exclusivement par les drivers des cartes graphiques, et leur mise à jour se fait donc en même temps que ces drivers (qui sont toujours disponibles sur le site du fabricant), la fréquence de mise à jour étant en moyenne tous les mois.
C'est le choix de l'utilisateur de faire ces mises à jour ou pas.

Par contre il faut que l'application, en l'occurrence le logiciel de montage FCPX ou Adobe Premiere ou Resolve, soit capable d'interfacer correctement ces nouvelles versions d'API, et là il s'agit de la mise à jour de l'application.

En général , en aucun cas, le système d'exploitation n'est concerné.

Olivier

 

Je vais répéter en précisant ce que je disais plus haut. : "Non pas que je ne comprenne pas l'idée que tu exprimes"...
Et plus bas détailler certains points non seulement aux PCistes peu concernés forcément, mais aussi aux Mac-users peu intéressés par la chose.

Parce que OpenCL et Cuda, je sais très bien ce que c'est, comment ça fonctionne et mieux comment fonctionnent les appli 64 bits, celles bien "multithreadées" ou moins bien, voire même comment on procède pour les développer... En outre, je connais encore mieux OSX, ce qui ne gâchera rien normalement dans ce contexte.
Je me permet donc si ça ne vous dérange pas de corriger le cas échéant, par ex. ça :

Non, pas "exclusivement". Apple fournit l'OpenCL par défaut déjà, et la met à jour tout comme elle met à jour petit à petit (et assez lentement) et régulièrement les API de sa sous-couche FreeBSD, quand bien même les lib sont dispo depuis longtemps. De lus, Apple a opté pour AMD depuis Mavericks et les derniers MacPro, donc ils deviennent un peu plus rapidement à jour.
Et surprise, elle fournit aussi un driver nvidia, voir en-dessous.
Donc juste pour dire qu'en dehors des API fournies par les fabriquants ou les détenteurs de brevets de technos, Apple fournit sa petite solution maison, quelle que soit son efficacité ou utilité.

Pour aller plus loin sur ce sujet ou plutôt voir que ça implique, et là spécifiquement sur OSX, on peut mettre des CG de PCs sur des Mac depuis OSX.7 (Lion, soit depuis disons 4-5 ans). Pourquoi ?
Parce que les drivers nVidia sont inclus d'origine dans l'OS, un driver "générique" plus précisément, qui permettra d'avoir n'importe quelle GTX xxx etc sans que celle-ci soit estampillée "Mac Edition" comme il fallait que ce soit le cas avant (hors flashage).
Voici pourquoi il n'est pas obligatoire bien que très fortement conseillé d'avoir les drivers fabriquant.
Voyons ce que ça change pour ce cas NVidia : imaginons GTX 780 par exemple. L'utilisateur aura le choix d'installer ou non les élément nVidia; s'il le fait, il a Cuda et/ou le driver à installer, et donc ensuite 2 panneaux de préférences dans ses Préférences Système, que l'on voit ici chez moi dans la partie "Autres" en bas : http://www.repaire.net/forums/attachment.php?attachmentid=30338&stc=1&d=1422272212
Le détail du panneau CUDA : rien de très intéressant, sauf qu'il tient au courant des MAJ sans aller sur le site, et met aussi à jour tout seul si on lui demande et qu'il le fait à l'intérieur du panneau sans obligation de download d'un installeur. Voici : http://www.repaire.net/forums/attachment.php?attachmentid=30339&stc=1&d=1422272212
Le détail du panneau driver : on y voit le choix possible, celui dont je parlais plus haut, donc driver de OSX ou celui téléchargé de nvidia: http://www.repaire.net/forums/attachment.php?attachmentid=30340&stc=1&d=1422272212
Beaucoup plus intéressant pour 2 raisons.
1/ ça invalide la 2ème phrase que je voulais rectifier du post précédent ("En général, en aucun cas, le système d'exploitation n'est concerné."). Et bien si, le système est pas mal concerné, et on voit le choix de démarrer sur celui fourni par OSX ou sur celui de nvidia. Je détaillerai plus bas à ceux qui ne le savent pas ce que ça implique*. Et plutôt bas niveau, puisque non loin du noyau d'ailleurs;

2/ pour que la théorie marketing apple "on branche, ça marche" soit vérifiable, il faut bien que ça vienne de quelque part Et bien c'est principalement de là, puisque par ex. touts les drivers générique de tous les fabriquants d'imprimantes sont fournis aussi, pareil pour les mass storage etc... Donc évidemment on peut toujours faire le choix de choisir celui que le fabriquant aura décidé de dev. pour OSX, mais hormis les points important (comme justement une carte graphique), on peut s'en foutre et jeter tous les CDs d'install. fournis avec les périphériques qu'on achète.

Pour OpenCL et donc AMD, c'est moins que ça : on ne fait rien du tout et c'est ok. Pas mal non...

* voici maintenant le détail de ce qui changera avec une CG PC plutôt que MacEdition lorsqu'elle existe. Ceci est donc plus à l'attention des Macusers :

a) pas de pomme sur fond gris au démarrage. L'écran restera noir jusqu'au panneau de login utilisateur (si choisi) ou à l'affichage du bureau. Ça fait toujours très peur au nouveau propriétaire d'un CG qui le met sur sa machine Apple ça.
Pourquoi ? Parce qu'il n'y a pas d'EFI sur la carte pas MacEdition. Bref, rien de très intéressant quoi ;

b) si l'on veut démarrer sur un autre système, il faudra le dire avant de redémarrer ou d'éteindre, car faire alt + boot n'affichera donc pas le choix des disques qui ont un système bootable.... puisque le panneau est là mais l'écran est noir

c) ça va couter 150€ de moyenne en moins. Ce qui vous en conviendrez ne valait pas le coup pour 8s. de pomme sur fond gris

Voilà. Je sais que j'en ai profité pour donner des infos qui sortent du sujet ici, mais la carte graphique étant une des préoccupations majeures liée à Resolve, c'est peut-être pas mal d'en informer les utilisateurs et de faire le point sur CUDA et OpenCL.

 

"par ex. touts les drivers générique de tous les fabriquants d'imprimantes sont fournis aussi, pareil pour les mass storage etc... "

Cela est également vrai pour Windows,
SI
- on a demandé et accepté les mises à jour automatiques
- si on accepte aussi les mises à jour des drivers par Windows

ce que je déconseille fortement, car très souvent ces mises à jour, ne sont pas à jour, et peuvent entrainer des régressions par rapport à la dernière version prise chez le constructeur.

=> "il vaut toujours mieux s'adresser à Dieu qu'à ses saints"

Donc je pense qu'il n'y a rien de vraiment différent sur Mac.

"Donc juste pour dire qu'en dehors des API fournies par les fabriquants ou les détenteurs de brevets de technos, Apple fournit sa petite solution maison, quelle que soit son efficacité ou utilité"

A l'origine ces API sont obligatoirement développées par le constructeur du matériel qui seul connait les internes des cartes qu'il produit.
Apple se contente de rajouter une "surcouche" pour personnaliser l'interface et s'adapter éventuellement à un microcode qu'il a demandé au constructeur de lui réaliser spécifiquement (cas des cartes estampillées Mac).

Olivier

 

Non, on ne parle pas de la même chose, et justement il y a quelque chose de différent, mais bon le topo n'était pas fait pour faire une distinction Mac/PC qui est très peu pertinente dans le contexte.
Brièvement, SANS accepter quelque MAJ que ce soit du fabriquant ou du système, le système initial OSX lira tout from scratch, pour ces raisons d'inclusions bas niveau. Voici une des différences.
Après, la politique de chacun quant aux maj auto ou pas et son ressenti par rapport aux régressions ou pas, c'est autre chose (moi je suis assez d'accord avec toi sur ce point de vue, mais c'est à la discrétion de chacun).

Le truc ok, c'est qu'évidemment les microcodes de départ sont fournis par les fabricants. Ça oui, c'est clair.

Autre chose : le fait qu'une carte soit estampillée "mac édition", c'est pas (seulement) pour la faire payer plus chère, qu'elle a passé les tests adequats ou qu'on lui a greffé un EFI pour des options au boot, c'est aussi que c'est une version qui ne nécessitera qu'un seul câble d'alim'.
Ceci a aussi son importance dans le contexte multiGPU de Resolve, selon les souhaits de config. de chacun.