Top config PC MAO 2022 (test, bench, discussion, débat...)
- 1 183 réponses
- 68 participants
- 77 076 vues
- 82 followers
Afficher le sujet de la discussion
Tiens, v'là un plugin trouvé au pif. Et il y'a effectivement Braingines, cité plus haut par Danbei. Et sûrement d'autres...
Ceci dit pour les DAWs, il semblerait effectivement qu'aucun ne le fasse pour l'instant. Les quelques discussions que j'ai retrouvées sur les forums de Cockos (Reaper) évoquent bien une tentative d'accélération des calculs via GPU, mais... Il s'agit de rendu graphique. Comme je pensais que Reaper le faisait déjà, j'avais dû supposer qu'il s'agissait de rendu audio, mais en fait non, Reaper affiche son interface via le pipeline graphique du l'OS et c'est tout. Bref, je m'est fourvoyé.
Techniquement, un GPU est un co-processeur arithmétique qui peut effectuer exactement les mêmes calculs qu'un CPU ; seuls les jeux d'instructions spécialisés diffèrent, et de fait les interfaces de programmation qui les exploitent (API). Les GPUs ont été à l'origine créés comme des unités de calcul graphiques, donc forcément les API étaient prévues spécifiquement pour optimiser ce type de calcul.
Mais y'a du chemin qui a été fait depuis, entre les calculs physiques (PhysX/Havok), puis CUDA suivi d'OpenCL qui permettent de distribuer n'importe quel type de calcul temps-réel... D'ailleurs fun fact : le premier DSP commercialisé par UAD était en réalité une puce de rendu 3D MPACT2 alors fabriquée par une filiale de... ATI ! La même puce équipait les cartes graphiques Nitro DVD à la fin des 90's !
Et maintenant c'est NVidia se place en bonne position sur l'IA, toujours traitée sur GPU à l'aide des Tensor Cores sur les cartes RTX.
Du coup si tu peux me trouver une bonne raison pour que l'architecture hardware des GPU actuels soit incapable de traiter de l'audio en temps réel, je suis preneur ! Parce que de mon point de vue, le facteur limitant c'est seulement la partie logicielle, notamment le manque criant d'API dédiée à ça. Mais n'étant pas développeur GPU moi-même, je peux complètement ignorer certaines limites inhérentes à l'architecture.
edit : un début de réponse ici pour ceux qui n'ont pas peur des "tech talks", et un papier complet qui explique les tenants et les aboutissants du GPGPU pour l'audio temps réel.
Et moi j'apprécierais un ton plus courtois et moins inquisiteur, histoire que ça reste une discussion à la cool entre gens sympas
Mais sinon tu peux commencer par la lecture des docs techniques de NVidia pour le SDK Audio Effects, qui permet de traiter du son en temps réel sur les cartes RTX. La version publique de l'outil permet actuellement de traiter jusqu'à 4 flux 48 kHz/32-bit float. La version accessible aux partenaires supporte 8 flux 96 kHz / 32-bit float, avec quelques restrictions sur ce que le GPU peut faire à côté. Et comme je le disais, à l'heure actuelle c'est principalement utilisé pour le streaming et autres broadcasts, mais rien n'empeche de développer des plugins basé sur les fonctionnalités offertes par ce SDK (et mine de rien, y'en a une belle liste qui pourrait être tout aussi utile en live qu'en studio). Vu que nous (dans le jeu vidéo) on le fait déjà, je serais très surpris que des boîtes comme iZotope ne considèrent pas cette possibilité...
Là, maintenant, je n'ai pas de sources sous la main, mais je vais tenter de retrouver (puisque je suis le premier à demander des sources! c'est la moindre des chose! ). Sauf que pour avoir souvent abordé ce sujet, ici comme ailleurs, je me souviens très bien qu'un développeur (de plugin je crois) expliquait pourquoi les GPU ne conviennent pas pour faire du calcul audio en temps réel et pourquoi aucun développeur n'empruntait cette « avenue ». Si c'était le cas, avec la puissance des cartes graphiques, depuis le temps, ça ferait longtemps que tous les éditeurs de DAW et plugins auraient tenté de tirer parti des cartes graphiques!
Je sais, c'est contre-intuitif a priori, car l'on se dit qu'une carte graphique doit forcément calculer en temps réel pour les jeux, mais à l'époque j'avais très bien saisi l'explication du dev, qui était des plus logique.
Je vais rechercher et revenir ensuite partager...
Désolé si cela t'a paru un peu « sec/inquisiteur », ce n'était pas mon intention. J'ai juste demandé des sources pourtant.
Je vais d'ailleurs moi-même tenter de retrouver celles qui appuient mon propos.
Y a pas de problème à ne pas avoir le même avis, c'est même bien, car ça nous pousse à faire des recherches pour confirmer ou infirmer nos opinions.
Une des idées principale du modèle d'exécution sur GPU c'est la parallélisme massif. Un GPU récent dispose de l'ordre de quelques milliers de cœurs, par exemple de 2500 à 10700 pour la dernière série NVIDIA (GeForce 30 series). Ce sont des cœurs qui sont beaucoup moins puissant que les cœurs CPU, attention il ne faut pas les mettre en face, ils sont très différents, mais très nombreux. On peut aussi lire une rapide introduction au GPU ici (le paragraphe "The Benefits of Using GPUs").
Mais c'est pire que ça, sur GPU il y a la même idée que le SMT/Hyperthreading CPU mais poussé encore plus loin, sur un GPU on exécute typiquement plusieurs centaines de milliers de threads pour exploiter toute la puissance de calcul d'un GPU récent. Utiliser autant de thread qu'il y a de cœur sur GPU est souvent très insuffisant pour obtenir des performances intéressantes. Dans ces spec on voit qu'on peut aller jusqu'à 2048 threads par SMX, et en fait on veut souvent en avoir au moins 2048 pour bien exploiter le SMX, sur une 3080 il y a 80 SMX (GeForce 30 series) : on veut au moins 2048*80=163 840 threads pour occuper correctement le GPU.
Autre contrainte, les GPU sont efficaces quand on exécute exactement le même code sur tous les threads. On peut coder un logiciel qui ferait des calculs différents sur chaque threads, mais c'est pas performant et du coup on évite (SIMT architecture).
Tout est exécutable sur GPU, mais tout n'est pas efficace, il faut que les algo soit massivement parallélisable.
Pour illustrer une des grandes différences entre l'image et le son : dans une image 1080p on a 2 millions de pixels, dans un buffer audio on a 32-1024 échantillons ! On peut tout à fait faire des calculs sur GPU avec un buffer de 32 échantillons, mais on va très largement sous exploiter la puissance disponible, c'est pas rentable.
A partir de la on peut :
- Utiliser des buffer beaucoup plus grand : plusieurs centaines de milliers d'échantillons, ce qui veut dire des latences de l'ordre de la seconde
- Appliquer les traitements sur plusieurs canaux. "Plusieurs" au sens de 100, 1000, pas au sens de 2 ou 3
. Attention ici ca veut dire qu'il faudrait appliquer le même traitement à tout les canaux. Si on veut vraiment profiter de la puissance de calcul GPU on évitera d'appliquer un gain sur un canal, on compresseur sur un autre etc.
- Il y a peut être d'autres idées auxquelles je ne pense pas
L'article "un papier complet qui explique les tenants et les aboutissants du GPGPU pour l'audio temps réel" montre bien la difficulté à la page 5 :
Pour 1 canal avec un buffer de 1024 échantillons (ce qui est appelé "temps réel" *), c'est plus lent sur GPU et c'est seulement quand on applique les traitements (le même appliqué à tous les canaux) sur 128 canaux qu'on bénéficie de la puissance du GPU. Sachant que les résultats de cet article ont été obtenue avec un un GPU GTX780M avec ~1500 cœurs CUDA, l'équivalent aujourd'hui serait une 3080 avec 10200 cœurs CUDA et le phénomène serait encore plus marqué.
* La notion de temps réel n'est pas très précise, dans cet article et dans les slides "un début de réponse ici" ils parlent de temps réel pour des buffer de 512-1024 échantillons et plus, soit déjà plusieurs dizaines de ms de latence, plus que ce que l'on considère comme temps réel en MAO.
De la même manière, pour ce qui est de Audio effects de NVIDIA il est ici indiqué que les traitements impliquent un minimum de 30ms de latence.
Attention aux articles d'il y a quelques années : à l'époque les GPU n'avait "que" quelques centaines de cœurs et on avait besoin d'autant moins de parallélisme pour les exploiter. D'où le fait qu'à l'époque plusieurs se sont légitimement poser la question de faire des traitements audio sur GPU. Et c'est pour cela que je dis que les GPU on progressés dans un sens qui n'est pas adapté au traitement audio : on a multiplié le nombre de cœurs par presque 20 en 10 ans
.
De plus, les dernières fonctionnalité GPU ce sont des unités de calcul spécialisées pour le calcul tensorielle, le tracé de rayon, le calcul en faible précision, des choses qu'on ne peut pas systématiquement appliquer au traitement audio. On peut utiliser les unités de calcul faible précision et de calcul tensorielle pour faire de l'inférence, mais c'est pas applicable à tout les traitements audio de manière général... Ma conclusion c'est que plus ça va plus les GPU s'éloignent de ce qu'on voudrait pour faire du traitement audio.
Voilà, c'est exactement ce que le dev de l'interview que je ne retrouve pas expliquait, grosso modo, à l'époque. Thx Danbei
C'est pour ça que dans mon dernier message, je dis que ce qui a été testé ce n'est que la latence induite par les échanges, mais que cela ne nous renseigne pas sur le gain de perf. Parce que si, pour gagner en perfs, il faut remonter au point où cela ajoute trop de latence pour bosser en temps réel, alors ça ne sert à rien.
Par contre, dans le papier que j'ai partagé Danbei, pour le premier tableau (Table 3), même avec un buffer au max, les latences observées (pour les échange CPU ==>GPU) demeurent à moins de 0.5ms.
Est-ce donc à dire que cela a changé depuis? Tu en pense quoi Danbei? Est-ce que j'interprète bien les résultats?
À moins, comme je ne le pense, que cela ne concerne que strictement des échanges sans considérer ce qu'il y aurait à traiter (dans le cadre d'un gros projet dans un DAW) ?
Ce tableau sert à vérifier que le temps total soit en dessous de 1000 ms, sinon ça veut dire que ça "glitch".
Avec un buffer de 32786 échantillons la latence final pour l'utilisateur à 44.1KHz est à 32786/44.1 ms = 743 ms.
La conclusion de l'article est qu'il est possible de faire du temps réel avec un GPU, la question suivante c'est : est ce que, dans un contexte en temps réel, un GPU est plus performant qu'un CPU ? Parce que pour faire du temps réel avec un GPU il faudra probablement rogner sur les performances.
Je suis d'accord sur le fond (la conclusion), mais....
...Je ne suis pas sûr de comprendre leur tableau. Dans celui-ci, par exemple :
si je regarde pour le buffer à 256smp, pour la GeForce2080 (avec OpenCL), le « total time » (donc latence audio + jitter) indique 24.731 alors que la latence indique 0.142 et le jitter 0.217
Premièrement, est-ce que les valeurs sont en seconde ou en ms? Moi je comprends (par la lecture du reste du papier) qu'il s'agit de ms, donc 24ms, 0.142ms et 0.217ms.
De plus, je ne comprends pas le résultat du « total time » puisque 0.142 + 0.217 = 0.359!!!
Donc à quoi correspond la valeur « totale » de 24.731?
csurieux
659
Posteur·euse AFfolé·e
Membre depuis 7 ans
ElliotValentine
858
Posteur·euse AFfolé·e
Membre depuis 8 ans
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 21 ans
Snowfall
1694
AFicionado·a
Membre depuis 12 ans
Sarakyel
2801
Squatteur·euse d’AF
Membre depuis 13 ans
Citation de Darkmoon :
Nous avons déjà eu cette discussion. Pour l'export, je veux bien (c'est possible techniquement), mais pour le temps réel, aucun DAW et plugins n'exploite le GPU (pour des calculs audio, je précise!) à ma connaissance
Tiens, v'là un plugin trouvé au pif. Et il y'a effectivement Braingines, cité plus haut par Danbei. Et sûrement d'autres...
Ceci dit pour les DAWs, il semblerait effectivement qu'aucun ne le fasse pour l'instant. Les quelques discussions que j'ai retrouvées sur les forums de Cockos (Reaper) évoquent bien une tentative d'accélération des calculs via GPU, mais... Il s'agit de rendu graphique. Comme je pensais que Reaper le faisait déjà, j'avais dû supposer qu'il s'agissait de rendu audio, mais en fait non, Reaper affiche son interface via le pipeline graphique du l'OS et c'est tout. Bref, je m'est fourvoyé.
Citation de Darkmoon :
les GPU ne sont pas conçus pour traiter du temps réel en basse latence.
Techniquement, un GPU est un co-processeur arithmétique qui peut effectuer exactement les mêmes calculs qu'un CPU ; seuls les jeux d'instructions spécialisés diffèrent, et de fait les interfaces de programmation qui les exploitent (API). Les GPUs ont été à l'origine créés comme des unités de calcul graphiques, donc forcément les API étaient prévues spécifiquement pour optimiser ce type de calcul.
Mais y'a du chemin qui a été fait depuis, entre les calculs physiques (PhysX/Havok), puis CUDA suivi d'OpenCL qui permettent de distribuer n'importe quel type de calcul temps-réel... D'ailleurs fun fact : le premier DSP commercialisé par UAD était en réalité une puce de rendu 3D MPACT2 alors fabriquée par une filiale de... ATI ! La même puce équipait les cartes graphiques Nitro DVD à la fin des 90's !
Et maintenant c'est NVidia se place en bonne position sur l'IA, toujours traitée sur GPU à l'aide des Tensor Cores sur les cartes RTX.
Du coup si tu peux me trouver une bonne raison pour que l'architecture hardware des GPU actuels soit incapable de traiter de l'audio en temps réel, je suis preneur ! Parce que de mon point de vue, le facteur limitant c'est seulement la partie logicielle, notamment le manque criant d'API dédiée à ça. Mais n'étant pas développeur GPU moi-même, je peux complètement ignorer certaines limites inhérentes à l'architecture.
edit : un début de réponse ici pour ceux qui n'ont pas peur des "tech talks", et un papier complet qui explique les tenants et les aboutissants du GPGPU pour l'audio temps réel.
Citation de Darkmoon :
J'apprécierai des preuves, des sources sur ce que tu avances Sarakyel
Et moi j'apprécierais un ton plus courtois et moins inquisiteur, histoire que ça reste une discussion à la cool entre gens sympas
Mais sinon tu peux commencer par la lecture des docs techniques de NVidia pour le SDK Audio Effects, qui permet de traiter du son en temps réel sur les cartes RTX. La version publique de l'outil permet actuellement de traiter jusqu'à 4 flux 48 kHz/32-bit float. La version accessible aux partenaires supporte 8 flux 96 kHz / 32-bit float, avec quelques restrictions sur ce que le GPU peut faire à côté. Et comme je le disais, à l'heure actuelle c'est principalement utilisé pour le streaming et autres broadcasts, mais rien n'empeche de développer des plugins basé sur les fonctionnalités offertes par ce SDK (et mine de rien, y'en a une belle liste qui pourrait être tout aussi utile en live qu'en studio). Vu que nous (dans le jeu vidéo) on le fait déjà, je serais très surpris que des boîtes comme iZotope ne considèrent pas cette possibilité...
[ Dernière édition du message le 19/02/2022 à 02:35:56 ]
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 21 ans
Citation de Sarakyel :
Techniquement, un GPU est un co-processeur arithmétique qui peut effectuer exactement les mêmes calculs qu'un CPU ; seuls les jeux d'instructions spécialisés diffèrent [...] Du coup si tu peux me trouver une bonne raison pour que l'architecture hardware des GPU actuels soit incapable de traiter de l'audio en temps réel, je suis preneur !
Là, maintenant, je n'ai pas de sources sous la main, mais je vais tenter de retrouver (puisque je suis le premier à demander des sources! c'est la moindre des chose!
). Sauf que pour avoir souvent abordé ce sujet, ici comme ailleurs, je me souviens très bien qu'un développeur (de plugin je crois) expliquait pourquoi les GPU ne conviennent pas pour faire du calcul audio en temps réel et pourquoi aucun développeur n'empruntait cette « avenue ». Si c'était le cas, avec la puissance des cartes graphiques, depuis le temps, ça ferait longtemps que tous les éditeurs de DAW et plugins auraient tenté de tirer parti des cartes graphiques!Je sais, c'est contre-intuitif a priori, car l'on se dit qu'une carte graphique doit forcément calculer en temps réel pour les jeux, mais à l'époque j'avais très bien saisi l'explication du dev, qui était des plus logique.
Je vais rechercher et revenir ensuite partager...
Citation de Sarakyel :
Citation de Darkmoon :J'apprécierai des preuves, des sources sur ce que tu avances Sarakyel
Et moi j'apprécierais un ton plus courtois et moins inquisiteur, histoire que ça reste une discussion à la cool entre gens sympas
Désolé si cela t'a paru un peu « sec/inquisiteur », ce n'était pas mon intention. J'ai juste demandé des sources pourtant.
Je vais d'ailleurs moi-même tenter de retrouver celles qui appuient mon propos. Y a pas de problème à ne pas avoir le même avis, c'est même bien, car ça nous pousse à faire des recherches pour confirmer ou infirmer nos opinions.
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
[ Dernière édition du message le 19/02/2022 à 03:56:58 ]
ElliotValentine
858
Posteur·euse AFfolé·e
Membre depuis 8 ans
efbie
534
Posteur·euse AFfolé·e
Membre depuis 21 ans
Danbei
1894
AFicionado·a
Membre depuis 14 ans
Citation de Sarakyel :
Du coup si tu peux me trouver une bonne raison pour que l'architecture hardware des GPU actuels soit incapable de traiter de l'audio en temps réel, je suis preneur !
Une des idées principale du modèle d'exécution sur GPU c'est la parallélisme massif. Un GPU récent dispose de l'ordre de quelques milliers de cœurs, par exemple de 2500 à 10700 pour la dernière série NVIDIA (GeForce 30 series). Ce sont des cœurs qui sont beaucoup moins puissant que les cœurs CPU, attention il ne faut pas les mettre en face, ils sont très différents, mais très nombreux. On peut aussi lire une rapide introduction au GPU ici (le paragraphe "The Benefits of Using GPUs").
Mais c'est pire que ça, sur GPU il y a la même idée que le SMT/Hyperthreading CPU mais poussé encore plus loin, sur un GPU on exécute typiquement plusieurs centaines de milliers de threads pour exploiter toute la puissance de calcul d'un GPU récent. Utiliser autant de thread qu'il y a de cœur sur GPU est souvent très insuffisant pour obtenir des performances intéressantes. Dans ces spec on voit qu'on peut aller jusqu'à 2048 threads par SMX, et en fait on veut souvent en avoir au moins 2048 pour bien exploiter le SMX, sur une 3080 il y a 80 SMX (GeForce 30 series) : on veut au moins 2048*80=163 840 threads pour occuper correctement le GPU.
Autre contrainte, les GPU sont efficaces quand on exécute exactement le même code sur tous les threads. On peut coder un logiciel qui ferait des calculs différents sur chaque threads, mais c'est pas performant et du coup on évite (SIMT architecture).
Tout est exécutable sur GPU, mais tout n'est pas efficace, il faut que les algo soit massivement parallélisable.
Pour illustrer une des grandes différences entre l'image et le son : dans une image 1080p on a 2 millions de pixels, dans un buffer audio on a 32-1024 échantillons ! On peut tout à fait faire des calculs sur GPU avec un buffer de 32 échantillons, mais on va très largement sous exploiter la puissance disponible, c'est pas rentable.
A partir de la on peut :
- Utiliser des buffer beaucoup plus grand : plusieurs centaines de milliers d'échantillons, ce qui veut dire des latences de l'ordre de la seconde
- Appliquer les traitements sur plusieurs canaux. "Plusieurs" au sens de 100, 1000, pas au sens de 2 ou 3
. Attention ici ca veut dire qu'il faudrait appliquer le même traitement à tout les canaux. Si on veut vraiment profiter de la puissance de calcul GPU on évitera d'appliquer un gain sur un canal, on compresseur sur un autre etc.- Il y a peut être d'autres idées auxquelles je ne pense pas
L'article "un papier complet qui explique les tenants et les aboutissants du GPGPU pour l'audio temps réel" montre bien la difficulté à la page 5 :
Pour 1 canal avec un buffer de 1024 échantillons (ce qui est appelé "temps réel" *), c'est plus lent sur GPU et c'est seulement quand on applique les traitements (le même appliqué à tous les canaux) sur 128 canaux qu'on bénéficie de la puissance du GPU. Sachant que les résultats de cet article ont été obtenue avec un un GPU GTX780M avec ~1500 cœurs CUDA, l'équivalent aujourd'hui serait une 3080 avec 10200 cœurs CUDA et le phénomène serait encore plus marqué.
* La notion de temps réel n'est pas très précise, dans cet article et dans les slides "un début de réponse ici" ils parlent de temps réel pour des buffer de 512-1024 échantillons et plus, soit déjà plusieurs dizaines de ms de latence, plus que ce que l'on considère comme temps réel en MAO.
De la même manière, pour ce qui est de Audio effects de NVIDIA il est ici indiqué que les traitements impliquent un minimum de 30ms de latence.
Attention aux articles d'il y a quelques années : à l'époque les GPU n'avait "que" quelques centaines de cœurs et on avait besoin d'autant moins de parallélisme pour les exploiter. D'où le fait qu'à l'époque plusieurs se sont légitimement poser la question de faire des traitements audio sur GPU. Et c'est pour cela que je dis que les GPU on progressés dans un sens qui n'est pas adapté au traitement audio : on a multiplié le nombre de cœurs par presque 20 en 10 ans
.De plus, les dernières fonctionnalité GPU ce sont des unités de calcul spécialisées pour le calcul tensorielle, le tracé de rayon, le calcul en faible précision, des choses qu'on ne peut pas systématiquement appliquer au traitement audio. On peut utiliser les unités de calcul faible précision et de calcul tensorielle pour faire de l'inférence, mais c'est pas applicable à tout les traitements audio de manière général... Ma conclusion c'est que plus ça va plus les GPU s'éloignent de ce qu'on voudrait pour faire du traitement audio.
[ Dernière édition du message le 19/02/2022 à 13:10:01 ]
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 21 ans
@Sarakyel
J’avais loupé une page (encore,
quand j’suis sur smartphone ça arrive et/ou ça bogue 
) et je vois que dans ton échange avec Danbei (msg #199) tu admets avoir conclus et présumé certains trucs, à tort.
Au final (ce que vous échangez tous les deux), ça revient à ce que je voulais exprimer : il n’y a pas — présentement — de DAW, ni de plugins (comprendre un environnement complet), qui exploitent nos cartes graphiques pour faire du calcul audio en temps réel.
Et ce qui m’importe, c’est surtout le fait de ne pas conseiller à quelqu’un (qui vient demander des conseils ici) de s’acheter telle ou telle carte graphique sous prétexte que certains DAW ou plugins l’utiliseront (et/ou, de par nos propos, donner l’impression qu’il y aura un gain de perf, un avantage, en MAO, à posséder une carte graphique non intégrée). Pour l’instant, un IGPU (puce intégrée à la CM) est tout à fait suffisant pour bosser dans un DAW et les quelques « tests/essais » qui tentent d’exploiter les cartes graphiques (pour calculer de l’audionumérique) sont rarissime (et/ou fonctionnent en application « standalone », mais pas en tant que plugin dans un DAW) et donc pas suffisant pour prendre en compte l’achat d’une carte graphique dans « l’équation » de l’achat d’un PC dédié MAO. Tel est mon propos et ce qui m’importe, précisément!
Maintenant, pour le reste, oui, depuis près de 20 ans maintenant, comme plusieurs, j’ai souvent lu « ici et là » que certaines entreprises et/ou universités effectuaient de la recherche, des tests et essais sur le sujet. Et c’est justement ce qui contribue à ramener le sujet dans certaines discussions de certains forums de temps à autre (il y a tjrs un mec pour dire « hey, mais pourquoi nos DAW et plugins n’utilisent pas nos cartes graphiques? » Moi même je me souviens m’être fait la même réflexion au début des années 2000). Par exemple, déjà, ici, en 2004, nous pouvions lire dans un article de 01net que la société BionicFX avait eu l’idée d’utiliser les capacités de calcul de la puce graphique pour traiter de l’audio en temps réel. C’est donc dire que l’idée est loin d’être « nouvelle »!
Sauf qu’entre avoir l’idée, effectuer des tests et de la recherche VS que ce soit dispo et fonctionnel au sein de nos workflows habituels à l’intérieur de nos DAW + plugins, il y a un monde! Et ce n’est manifestement pas encore disponible.
Sinon, je n’ai pas retrouvé l’interview spécifique avec le dev dont je parlais, ça m’emmerde, mais bon. Et sinon, oui, en effet, de temps à autre, nous tombons sur des « papiers de recherche » comme celui que tu as partagé en lien (thx!). D’ailleurs, j’en ai également trouvé un autre, encore plus récent (juillet 2020!!) ici intitulé :
There and Back Again: The Practicality of GPU Accelerated Digital Audio (PDF)
Ou ici directement sur site et ici pour la présentation vidéo du NIME2020
C’est un autre « vrai papier scientifique » (complémentaire à celui que tu partages) avec un « abstract » (résumé), et de nombreuses références en dernière page.
Pour résumer (j’ai lu le papier dans son intégralité) :
- il s’agit surtout de recherches universitaires (sans doute dans le cadre de thèses),
- il s’agit uniquement d’observer si le coût des échanges de données~mémoires entre le CPU et le GPU est limitant ou non, au final. Et uniquement ça!
- surtout, ces recherches et tests ne sont pas effectués en situation réelle, c’est-à-dire avec un « OS » et un DAW (comme nous, « l’utilisateur final », bossons), mais qu’avec des outils spécifiques destinés (codé spécifiquement) qu’à ne mesurer que les échanges de données~mémoires entre le CPU et le GPU. C’est donc à dire que les résultats observés, c’est-à-dire les latences induites, sont (seraient) à ajouter à celle déjà effective dans notre chaîne de traitement habituelle,
- OpenCL permet d’exploiter les FPGA, les DSP, ainsi que les GPU (pour les vendeurs dont le matériel le supporte), mais CUDA est plus « problématique » car non compatible (puisque c’est une techno « propriétaire ) avec les cartes graphiques AMD (anciennement ATI),
- Il semble (ça, ce n’est pas ma formulation, c’est un copié/collé, mais traduit, d’un passage dans le papier) y avoir une prudence compréhensible au sein de la communauté des développeurs audio numérique, une prudence à l’égard de la « GPGPU » (NDT : c’est le terme qui désigne l’exploitation des GPU pour des applications autres que graphiques), et par conséquent, l’optimisation « GPGPU » est peu utilisée.
Et pour ce qui est de leurs conclusions, concernant le test bidirectionnel pour des échantillons audio, les résultats de leur tableau sont toujours en déca de 1ms dès que la valeur du buffer est à 8smp ou plus. Sauf que pour ce tableau, l’on voit bien que ça n’a rien à voir avec une utilisation réelle, au sein d’un OS + DAW qui doit gérer des plugins tiers, etc., car aucune de nos machines actuelles n’arrive à bosser à 0.142ms, comme le genre de valeur que l’on observe dans leurs tableaux. Il est donc clair (c’est même précisé en préambule), qu’ils testent uniquement et précisément les latence induites par les échanges mémoire et données entre CPU et GPU afin de constater si l’échange entre les deux est limitant ou non. Il apparaît qu’il ne l’est pas (très peu), mais seulement sous les paramètres et le protocole de ce type de test qui ne prend pas en compte l’OS, ni le DAW, etc. Autrement dit, pour ce que j’en comprends, puisqu’il ne s’agit que d’observer la latence induite par les échanges entre le CPU et le GPU, il faut donc ajouter cette latence (celle des échanges observés dans ce papier) à celle déjà existante dans nos chaînes de traitement habituel (Interface audio, OS, DAW, plugins, etc.). Mais, bon, en regard des résultats, l’on peut dire qu’ajouter moins d’une milliseconde n’est pas limitant! Leur test démontre donc que ce serait possible, techniquement! C’est-à-dire que ça n’ajouterait pas trop de latence!
Par contre il y a aussi un autre tableau qui, pour ce que j’en comprends, montre les résultats pour de la modélisation physique (disons dans l’éventualité d’un VSTi de synthé) et, pour ce dernier, ça peut poser des problèmes de jitter à partir d’un buffer à 64smp. Et pour la latence, induire de 1ms à 8ms, entre un buffer à 128smp jusqu’à 512smp. Mais, encore, toujours dans le cadre de ce protocole particulier pour cette recherche universitaire. C’est-à-dire que la latence induite par ces échanges s’ajoutera à celle déjà induite par le reste de notre chaîne. Du coup, là, en ajoutant plus d’une seconde à partir de 128smp, c’est déjà moins « intéressant » pour de la modélisation.
Et il semble en être de même pour le papier que tu as partagé (je l’ai juste survolé en diago, car il est bcp plus « dense ». Sinon tu me corrigeras). Ce sont des programmes écrits spécifiquement pour ces tests (échanges données/mémoires entre CPU/GPU) qui sont utilisés, dans le but de démontrer la latence induite par ces échanges.
Sauf que pour ce qui nous intéresse nous, en tant qu’utilisateurs finaux, c’est qu’il faudrait que toute « l’industrie » suive afin qu’autant les DAW que les plugins puissent exploiter nos cartes graphiques. Et pour ce que j’en comprends, le principal problème vient, encore une fois (ce n'est pas nouveau, mais c'est un autres sujet ), du fait des normes et différentes technologies, dont certaines sont propriétaires, ce qui refroidi probablement les « ardeurs » et les « idées » de certains éditeurs. J’imagine que les éditeurs de DAW et plugins n’ont pas envie de se prendre la tête à « tous collaborer » afin que tel ou tel DAW et tel ou tel plugin soient « codés » afin d’exploiter CUDA alors que plusieurs de leurs clients possèdent des cartes graphiques AMD (anciennement ATI) ne pouvant exécuter CUDA. Et c’est fort probablement pourquoi que les seuls qui s’aventurent à exploiter autres chose que le CPU, pour l’audio, se rabattent plutôt sur des DSP ou FPGA, qu’ils incorporent dans leurs propres produits « propriéaire » ==> UAD, Antelope, etc. 
Bref, quand tu disais que ça dépendait des API et de la prog, c’était exact. En principe, en effet, il serait possible d’exploiter les GPU pour traiter (au moins) de l’audio sans ajouter plus de 0.140ms de latence. Par contre pour de la synthèse à modélisation physique, ça semble plus problématique.
Sauf qu’en pratique et dans les faits, bien que l’idée ait « émergé » il y a déjà près de 20 ans, ça semble trop compliqué (pas théoriquement, mais en pratique pour les éditeurs de produits) à mettre en œuvre au sein de « l’environnement global MAO ». Faudrait que tous se mettent d’accord pour utiliser le même API et j’imagine qu’autant l’interface audio, que le DAW, les plugins et l’OS devraient « bosser de pairs » pour gérer le tout (suis pas codeur, mais je présume ici).
Aussi, ces tests ne nous démontrent pas, outre la latence induite par les échanges en le CPU et le GPU, le gain de performance que ça nous procurerait (et c’est là tout l’intérêt!). Et pour cause, car ce n’est pas ce qui a été testé, car pour cela, ils devraient créer un « DAW » et des plugins (pour « simuler une utilisation standard typique) afin d’observer, P. Ex., combien de plugins et/ou la taille d’un projet MAO que pourrait gérer telle ou telle carte graphique.
Bref, ma conclusion est la suivante : nous n’en sommes qu’encore qu’au stade de la recherche et des balbutiements en ce domaine, les principaux acteurs semblent encore trop frileux pour emprunter cette « voie » et il n’existe pas encore d’environnement complet (comprendre ==> DAW et plusieurs plugins) permettant d’exploiter nos cartes graphiques pour faire de la MAO.
Mais tu as raison : techniquement, ce serait possible! Les récentes recherches démontrent que ça n’ajouterait pas plus que quelques centièmes de milliseconde de latence, dans certains cas!
J’avais loupé une page (encore,
quand j’suis sur smartphone ça arrive et/ou ça bogue ) et je vois que dans ton échange avec Danbei (msg #199) tu admets avoir conclus et présumé certains trucs, à tort.Au final (ce que vous échangez tous les deux), ça revient à ce que je voulais exprimer : il n’y a pas — présentement — de DAW, ni de plugins (comprendre un environnement complet), qui exploitent nos cartes graphiques pour faire du calcul audio en temps réel.
Et ce qui m’importe, c’est surtout le fait de ne pas conseiller à quelqu’un (qui vient demander des conseils ici) de s’acheter telle ou telle carte graphique sous prétexte que certains DAW ou plugins l’utiliseront (et/ou, de par nos propos, donner l’impression qu’il y aura un gain de perf, un avantage, en MAO, à posséder une carte graphique non intégrée). Pour l’instant, un IGPU (puce intégrée à la CM) est tout à fait suffisant pour bosser dans un DAW et les quelques « tests/essais » qui tentent d’exploiter les cartes graphiques (pour calculer de l’audionumérique) sont rarissime (et/ou fonctionnent en application « standalone », mais pas en tant que plugin dans un DAW) et donc pas suffisant pour prendre en compte l’achat d’une carte graphique dans « l’équation » de l’achat d’un PC dédié MAO. Tel est mon propos et ce qui m’importe, précisément!
Maintenant, pour le reste, oui, depuis près de 20 ans maintenant, comme plusieurs, j’ai souvent lu « ici et là » que certaines entreprises et/ou universités effectuaient de la recherche, des tests et essais sur le sujet. Et c’est justement ce qui contribue à ramener le sujet dans certaines discussions de certains forums de temps à autre (il y a tjrs un mec pour dire « hey, mais pourquoi nos DAW et plugins n’utilisent pas nos cartes graphiques? » Moi même je me souviens m’être fait la même réflexion au début des années 2000). Par exemple, déjà, ici, en 2004, nous pouvions lire dans un article de 01net que la société BionicFX avait eu l’idée d’utiliser les capacités de calcul de la puce graphique pour traiter de l’audio en temps réel. C’est donc dire que l’idée est loin d’être « nouvelle »!
Sauf qu’entre avoir l’idée, effectuer des tests et de la recherche VS que ce soit dispo et fonctionnel au sein de nos workflows habituels à l’intérieur de nos DAW + plugins, il y a un monde! Et ce n’est manifestement pas encore disponible.
Sinon, je n’ai pas retrouvé l’interview spécifique avec le dev dont je parlais, ça m’emmerde, mais bon. Et sinon, oui, en effet, de temps à autre, nous tombons sur des « papiers de recherche » comme celui que tu as partagé en lien (thx!
). D’ailleurs, j’en ai également trouvé un autre, encore plus récent (juillet 2020!!) ici intitulé :There and Back Again: The Practicality of GPU Accelerated Digital Audio (PDF)
Ou ici directement sur site et ici pour la présentation vidéo du NIME2020
C’est un autre « vrai papier scientifique » (complémentaire à celui que tu partages) avec un « abstract » (résumé), et de nombreuses références en dernière page.
Pour résumer (j’ai lu le papier dans son intégralité) :
- il s’agit surtout de recherches universitaires (sans doute dans le cadre de thèses),
- il s’agit uniquement d’observer si le coût des échanges de données~mémoires entre le CPU et le GPU est limitant ou non, au final. Et uniquement ça!
- surtout, ces recherches et tests ne sont pas effectués en situation réelle, c’est-à-dire avec un « OS » et un DAW (comme nous, « l’utilisateur final », bossons), mais qu’avec des outils spécifiques destinés (codé spécifiquement) qu’à ne mesurer que les échanges de données~mémoires entre le CPU et le GPU. C’est donc à dire que les résultats observés, c’est-à-dire les latences induites, sont (seraient) à ajouter à celle déjà effective dans notre chaîne de traitement habituelle,
- OpenCL permet d’exploiter les FPGA, les DSP, ainsi que les GPU (pour les vendeurs dont le matériel le supporte), mais CUDA est plus « problématique » car non compatible (puisque c’est une techno « propriétaire ) avec les cartes graphiques AMD (anciennement ATI),
- Il semble (ça, ce n’est pas ma formulation, c’est un copié/collé, mais traduit, d’un passage dans le papier) y avoir une prudence compréhensible au sein de la communauté des développeurs audio numérique, une prudence à l’égard de la « GPGPU » (NDT : c’est le terme qui désigne l’exploitation des GPU pour des applications autres que graphiques), et par conséquent, l’optimisation « GPGPU » est peu utilisée.
Et pour ce qui est de leurs conclusions, concernant le test bidirectionnel pour des échantillons audio, les résultats de leur tableau sont toujours en déca de 1ms dès que la valeur du buffer est à 8smp ou plus. Sauf que pour ce tableau, l’on voit bien que ça n’a rien à voir avec une utilisation réelle, au sein d’un OS + DAW qui doit gérer des plugins tiers, etc., car aucune de nos machines actuelles n’arrive à bosser à 0.142ms, comme le genre de valeur que l’on observe dans leurs tableaux. Il est donc clair (c’est même précisé en préambule), qu’ils testent uniquement et précisément les latence induites par les échanges mémoire et données entre CPU et GPU afin de constater si l’échange entre les deux est limitant ou non. Il apparaît qu’il ne l’est pas (très peu), mais seulement sous les paramètres et le protocole de ce type de test qui ne prend pas en compte l’OS, ni le DAW, etc. Autrement dit, pour ce que j’en comprends, puisqu’il ne s’agit que d’observer la latence induite par les échanges entre le CPU et le GPU, il faut donc ajouter cette latence (celle des échanges observés dans ce papier) à celle déjà existante dans nos chaînes de traitement habituel (Interface audio, OS, DAW, plugins, etc.). Mais, bon, en regard des résultats, l’on peut dire qu’ajouter moins d’une milliseconde n’est pas limitant! Leur test démontre donc que ce serait possible, techniquement! C’est-à-dire que ça n’ajouterait pas trop de latence!
Par contre il y a aussi un autre tableau qui, pour ce que j’en comprends, montre les résultats pour de la modélisation physique (disons dans l’éventualité d’un VSTi de synthé) et, pour ce dernier, ça peut poser des problèmes de jitter à partir d’un buffer à 64smp. Et pour la latence, induire de 1ms à 8ms, entre un buffer à 128smp jusqu’à 512smp. Mais, encore, toujours dans le cadre de ce protocole particulier pour cette recherche universitaire. C’est-à-dire que la latence induite par ces échanges s’ajoutera à celle déjà induite par le reste de notre chaîne. Du coup, là, en ajoutant plus d’une seconde à partir de 128smp, c’est déjà moins « intéressant » pour de la modélisation.
Et il semble en être de même pour le papier que tu as partagé (je l’ai juste survolé en diago, car il est bcp plus « dense ». Sinon tu me corrigeras
). Ce sont des programmes écrits spécifiquement pour ces tests (échanges données/mémoires entre CPU/GPU) qui sont utilisés, dans le but de démontrer la latence induite par ces échanges.Sauf que pour ce qui nous intéresse nous, en tant qu’utilisateurs finaux, c’est qu’il faudrait que toute « l’industrie » suive afin qu’autant les DAW que les plugins puissent exploiter nos cartes graphiques. Et pour ce que j’en comprends, le principal problème vient, encore une fois (ce n'est pas nouveau, mais c'est un autres sujet
), du fait des normes et différentes technologies, dont certaines sont propriétaires, ce qui refroidi probablement les « ardeurs » et les « idées » de certains éditeurs. J’imagine que les éditeurs de DAW et plugins n’ont pas envie de se prendre la tête à « tous collaborer » afin que tel ou tel DAW et tel ou tel plugin soient « codés » afin d’exploiter CUDA alors que plusieurs de leurs clients possèdent des cartes graphiques AMD (anciennement ATI) ne pouvant exécuter CUDA. Et c’est fort probablement pourquoi que les seuls qui s’aventurent à exploiter autres chose que le CPU, pour l’audio, se rabattent plutôt sur des DSP ou FPGA, qu’ils incorporent dans leurs propres produits « propriéaire » ==> UAD, Antelope, etc. Bref, quand tu disais que ça dépendait des API et de la prog, c’était exact.
En principe, en effet, il serait possible d’exploiter les GPU pour traiter (au moins) de l’audio sans ajouter plus de 0.140ms de latence. Par contre pour de la synthèse à modélisation physique, ça semble plus problématique.Sauf qu’en pratique et dans les faits, bien que l’idée ait « émergé » il y a déjà près de 20 ans, ça semble trop compliqué (pas théoriquement, mais en pratique pour les éditeurs de produits) à mettre en œuvre au sein de « l’environnement global MAO ». Faudrait que tous se mettent d’accord pour utiliser le même API et j’imagine qu’autant l’interface audio, que le DAW, les plugins et l’OS devraient « bosser de pairs » pour gérer le tout (suis pas codeur, mais je présume ici).
Aussi, ces tests ne nous démontrent pas, outre la latence induite par les échanges en le CPU et le GPU, le gain de performance que ça nous procurerait (et c’est là tout l’intérêt!). Et pour cause, car ce n’est pas ce qui a été testé, car pour cela, ils devraient créer un « DAW » et des plugins (pour « simuler une utilisation standard typique) afin d’observer, P. Ex., combien de plugins et/ou la taille d’un projet MAO que pourrait gérer telle ou telle carte graphique.
Bref, ma conclusion est la suivante : nous n’en sommes qu’encore qu’au stade de la recherche et des balbutiements en ce domaine, les principaux acteurs semblent encore trop frileux pour emprunter cette « voie » et il n’existe pas encore d’environnement complet (comprendre ==> DAW et plusieurs plugins) permettant d’exploiter nos cartes graphiques pour faire de la MAO.
Mais tu as raison : techniquement, ce serait possible! Les récentes recherches démontrent que ça n’ajouterait pas plus que quelques centièmes de milliseconde de latence, dans certains cas!
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 21 ans
Citation de Danbei :
Utiliser autant de thread qu'il y a de cœur sur GPU est souvent très insuffisant pour obtenir des performances intéressantes [...] Autre contrainte, les GPU sont efficaces quand on exécute exactement le même code sur tous les threads. On peut coder un logiciel qui ferait des calculs différents sur chaque threads, mais c'est pas performant et du coup on évite [...] Tout est exécutable sur GPU, mais tout n'est pas efficace, il faut que les algo soit massivement parallélisable [...] on peut tout à fait faire des calculs sur GPU avec un buffer de 32 échantillons, mais on va très largement sous exploiter la puissance disponible, c'est pas rentable [...] Utiliser des buffer beaucoup plus grand : plusieurs centaines de milliers d'échantillons, ce qui veut dire des latences de l'ordre de la seconde [...] Appliquer les traitements sur plusieurs canaux. "Plusieurs" au sens de 100, 1000 [...] Si on veut vraiment profiter de la puissance de calcul GPU on évitera d'appliquer un gain sur un canal, on compresseur sur un autre etc [...] Pour 1 canal avec un buffer de 1024 échantillons (ce qui est appelé "temps réel" *), c'est plus lent sur GPU et c'est seulement quand on applique les traitements (le même appliqué à tous les canaux) sur 128 canaux qu'on bénéficie de la puissance du GPU [...] Ma conclusion c'est que plus ça va plus les GPU s'éloignent de ce qu'on voudrait pour faire du traitement audio.
Voilà, c'est exactement ce que le dev de l'interview que je ne retrouve pas expliquait, grosso modo, à l'époque. Thx Danbei
Citation de Danbei :
on peut tout à fait faire des calculs sur GPU avec un buffer de 32 échantillons, mais on va très largement sous exploiter la puissance disponible, c'est pas rentable
C'est pour ça que dans mon dernier message, je dis que ce qui a été testé ce n'est que la latence induite par les échanges, mais que cela ne nous renseigne pas sur le gain de perf. Parce que si, pour gagner en perfs, il faut remonter au point où cela ajoute trop de latence pour bosser en temps réel, alors ça ne sert à rien.
Par contre, dans le papier que j'ai partagé Danbei, pour le premier tableau (Table 3), même avec un buffer au max, les latences observées (pour les échange CPU ==>GPU) demeurent à moins de 0.5ms.
Est-ce donc à dire que cela a changé depuis? Tu en pense quoi Danbei? Est-ce que j'interprète bien les résultats?À moins, comme je ne le pense, que cela ne concerne que strictement des échanges sans considérer ce qu'il y aurait à traiter (dans le cadre d'un gros projet dans un DAW) ?
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Danbei
1894
AFicionado·a
Membre depuis 14 ans
Citation de Darkmoon :
Je suis pas sur d'avoir compris à quoi tu compare ces résultats. Par contre, dans le papier que j'ai partagé Danbei, pour le premier tableau (Table 3), même avec un buffer au max, les latences observées (pour les échange CPU ==>GPU) demeurent à moins de 0.5ms.
Ce tableau sert à vérifier que le temps total soit en dessous de 1000 ms, sinon ça veut dire que ça "glitch".
Avec un buffer de 32786 échantillons la latence final pour l'utilisateur à 44.1KHz est à 32786/44.1 ms = 743 ms.
La conclusion de l'article est qu'il est possible de faire du temps réel avec un GPU, la question suivante c'est : est ce que, dans un contexte en temps réel, un GPU est plus performant qu'un CPU ? Parce que pour faire du temps réel avec un GPU il faudra probablement rogner sur les performances.
[ Dernière édition du message le 19/02/2022 à 16:42:07 ]
csurieux
659
Posteur·euse AFfolé·e
Membre depuis 7 ans
JohnnyG
10816
Drogué·e à l’AFéine
Membre depuis 16 ans
csurieux
659
Posteur·euse AFfolé·e
Membre depuis 7 ans
Snowfall
1694
AFicionado·a
Membre depuis 12 ans
csurieux
659
Posteur·euse AFfolé·e
Membre depuis 7 ans
Snowfall
1694
AFicionado·a
Membre depuis 12 ans
ElliotValentine
858
Posteur·euse AFfolé·e
Membre depuis 8 ans
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 21 ans
Citation de Danbei :
Ce tableau sert à vérifier que le temps total soit en dessous de 1000 ms, sinon ça veut dire que ça "glitch".
Avec un buffer de 32786 échantillons la latence final pour l'utilisateur à 44.1KHz est à 32786/44.1 ms = 743 ms.
La conclusion de l'article est qu'il est possible de faire du temps réel avec un GPU, la question suivante c'est : est ce que, dans un contexte en temps réel, un GPU est plus performant qu'un CPU ? Parce que pour faire du temps réel avec un GPU il faudra probablement rogner sur les performances.
Je suis d'accord sur le fond (la conclusion), mais....
...Je ne suis pas sûr de comprendre leur tableau. Dans celui-ci, par exemple :
si je regarde pour le buffer à 256smp, pour la GeForce2080 (avec OpenCL), le « total time » (donc latence audio + jitter) indique 24.731 alors que la latence indique 0.142 et le jitter 0.217
Premièrement, est-ce que les valeurs sont en seconde ou en ms? Moi je comprends (par la lecture du reste du papier) qu'il s'agit de ms, donc 24ms, 0.142ms et 0.217ms.
De plus, je ne comprends pas le résultat du « total time » puisque 0.142 + 0.217 = 0.359!!!
Donc à quoi correspond la valeur « totale » de 24.731?"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Danbei
1894
AFicionado·a
Membre depuis 14 ans
csurieux
659
Posteur·euse AFfolé·e
Membre depuis 7 ans
Toujours dans ma démarche de définir une config cible, j'en suis à me demanander si la solution originnelle, et qui semble très solide, proposée par Sarakyel et basée sur du I5-12600F, pour 200€ de plus, ne pourrait passer sur du I5-12600KF (qui semble en promo de ci de là) et proposer un niveau de puissance supérieur.
Ce serait passer à l'OC, j'ai pas mal lu dessus, et Intel semble proposer une solution très acceptable, donc ça ne m'effraie pas plus que ça.
J'ai aussi entendu que l'AMD 5600X ou 5800X pourraient être envisagés, mais là il me faut revoir la CM Gigabyte qui me plaisait bien, je traiterai ça en seconde priorité, souhaitant boucler le sujet sur Intel et le I5-12600KF.
Bref, mon problème en cas d'OC semble la gestion de ce surplus de chaleur et j'ai 'brulé' ,, des heures à visualiser des présentations de systèmes de refroidissement et de boitiers sur Youtube pour en arriver au constat qu'il me manquait un élément essentiel :
comment dimensionner un système de refroidissement ? Ce n'est quand même pas empirique, il doit bien exister une ou deux lois qui permettent, connaissant les températures atteintes par un processeur, de savoir combien de ventilateurs il faut utiliser dans son boitier en plus de ceux de son ventirad ?
A ce sujet, je note que le 'ARCTIC Freezer 34 eSports DUO' avec ses deux ventilateurs semble meilleur que le 'Cooler Master Silencio FP 120 PWM ' monté avec deux ventilateurs. Il semble aussi plus silencieux.
Ensuite il y a l'alim... et là les 550W de la 'Be Quiet Straight Power 11' semblent légers pour absorber les W de plus réclamés par l'OC du I5-12600KF, mais là aussi à quelle puissance monter, 750W pour être tranquile ?
La carte Gigabyte B660M DS3H DDR4, quant à elle, semble supporter l'OC et peut être conservée ?
Autre chose ? Le boitier 'Cooler Master Silencio S400' silencieux, ce qui me plait bien, chaufferait-t-il trop pour de l'OC ? Même en multipliant les ventilateurs ? J'ai regardé des démos de boitiers mais dans ces prix ils semblent tous plus bruyants, comme le 'Corsair Crystal 280X Noir' (plus cher) ? Ce qui est logique, plus ils laissent passer l'air de refroidissement, plus ils laissent sortir les ronflements...
Merci pour vos avis et corrections pour ma meilleure compréhension.
Ce serait passer à l'OC, j'ai pas mal lu dessus, et Intel semble proposer une solution très acceptable, donc ça ne m'effraie pas plus que ça.
J'ai aussi entendu que l'AMD 5600X ou 5800X pourraient être envisagés, mais là il me faut revoir la CM Gigabyte qui me plaisait bien, je traiterai ça en seconde priorité, souhaitant boucler le sujet sur Intel et le I5-12600KF.
Bref, mon problème en cas d'OC semble la gestion de ce surplus de chaleur et j'ai 'brulé' ,
, des heures à visualiser des présentations de systèmes de refroidissement et de boitiers sur Youtube pour en arriver au constat qu'il me manquait un élément essentiel :comment dimensionner un système de refroidissement ? Ce n'est quand même pas empirique, il doit bien exister une ou deux lois qui permettent, connaissant les températures atteintes par un processeur, de savoir combien de ventilateurs il faut utiliser dans son boitier en plus de ceux de son ventirad ?
A ce sujet, je note que le 'ARCTIC Freezer 34 eSports DUO' avec ses deux ventilateurs semble meilleur que le 'Cooler Master Silencio FP 120 PWM ' monté avec deux ventilateurs. Il semble aussi plus silencieux.
Ensuite il y a l'alim... et là les 550W de la 'Be Quiet Straight Power 11' semblent légers pour absorber les W de plus réclamés par l'OC du I5-12600KF, mais là aussi à quelle puissance monter, 750W pour être tranquile ?
La carte Gigabyte B660M DS3H DDR4, quant à elle, semble supporter l'OC et peut être conservée ?
Autre chose ? Le boitier 'Cooler Master Silencio S400' silencieux, ce qui me plait bien, chaufferait-t-il trop pour de l'OC ? Même en multipliant les ventilateurs ? J'ai regardé des démos de boitiers mais dans ces prix ils semblent tous plus bruyants, comme le 'Corsair Crystal 280X Noir' (plus cher) ? Ce qui est logique, plus ils laissent passer l'air de refroidissement, plus ils laissent sortir les ronflements...
Merci pour vos avis et corrections pour ma meilleure compréhension.
[ Dernière édition du message le 20/02/2022 à 20:33:17 ]
Snowfall
1694
AFicionado·a
Membre depuis 12 ans
csurieux
659
Posteur·euse AFfolé·e
Membre depuis 7 ans
Snowfall
1694
AFicionado·a
Membre depuis 12 ans
- < Liste des sujets
- Charte