Avant que la HD ne soit une chose, les processeurs pouvaient facilement gérer le décodage vidéo. Lorsque la HD est devenue populaire il y a environ 8 ans, les fabricants de GPU ont commencé à implémenter le décodage vidéo accéléré dans leurs puces. Vous pouvez facilement trouver des cartes graphiques commercialisées comme supportant des vidéos HD et d'autres slogans. Aujourd'hui, tout GPU prend en charge la vidéo accélérée, même les GPU intégrés comme Intel HD Graphics ou leurs prédécesseurs, Intel GMA. Sans cet ajout, votre processeur aurait du mal à digérer la vidéo 1080p avec un taux de rafraîchissement acceptable, sans parler de l'augmentation de la consommation d'énergie. Vous utilisez donc déjà la vidéo accélérée tous les jours.
Maintenant, lorsque les GPU ont une puissance de calcul de plus en plus générale, ils sont également largement utilisés pour accélérer le traitement vidéo. Cette tendance a commencé à peu près au même moment où le décodage accéléré a été introduit. Des programmes comme Badaboom ont commencé à gagner en popularité car il s'est avéré que les GPU sont bien meilleurs pour (ré) encoder la vidéo que les CPU. Cependant, cela ne pouvait pas être fait auparavant, car les GPU manquaient de capacités de calcul génériques.
Mais les GPU pouvaient déjà mettre à l'échelle, faire pivoter et transformer des images depuis le moyen-âge, alors pourquoi n'avons-nous pas pu utiliser ces fonctionnalités pour le traitement vidéo? Eh bien, ces fonctionnalités n'ont jamais été implémentées pour être utilisées de cette manière, elles étaient donc sous-optimales pour diverses raisons.
Lorsque vous programmez un jeu, vous téléchargez d'abord tous les graphiques, effets, etc. sur le GPU, puis vous ne faites que rendre des polygones et leur mapper les objets appropriés. Vous n'avez pas à envoyer de textures chaque fois qu'elles sont nécessaires, vous pouvez les charger et les réutiliser. En ce qui concerne le traitement vidéo, vous devez constamment alimenter les images dans le GPU, les traiter et les récupérer pour les réencoder sur le processeur (rappelez-vous, nous parlons de temps de pré-calcul GPU). Ce n'était pas ainsi que les GPU étaient censés fonctionner, donc les performances n'étaient pas excellentes.
Une autre chose est que les GPU ne sont pas axés sur la qualité en ce qui concerne les transformations d'images. Lorsque vous jouez à un jeu à plus de 40 images par seconde, vous ne remarquerez pas vraiment de fausses déclarations de pixels. Même si vous le vouliez, les graphiques du jeu n'étaient pas suffisamment détaillés pour que les gens s'en soucient. Diverses astuces et astuces utilisées pour accélérer le rendu peuvent légèrement affecter la qualité. Les vidéos sont également lues à des fréquences d'images assez élevées, il est donc acceptable de les redimensionner dynamiquement lors de la lecture, mais le réencodage ou le rendu doit produire des résultats parfaits en pixels ou au moins aussi proches que possible à un coût raisonnable. Vous ne pouvez pas y parvenir sans les fonctionnalités appropriées implémentées directement dans le GPU.
De nos jours, l'utilisation de GPU pour traiter des vidéos est assez courante car nous avons mis en place la technologie requise. Pourquoi ce n'est pas le choix par défaut est plutôt une question pour l'éditeur du programme, pas pour nous - c'est leur choix. Ils pensent peut-être que leurs clients ont un matériel orienté vers le traitement des vidéos sur le processeur, donc le passage au GPU affectera négativement les performances, mais c'est juste ma supposition. Une autre possibilité est qu'ils traitent toujours le rendu GPU comme une fonctionnalité expérimentale qui n'est pas encore assez stable pour le définir comme défaut par défaut. Vous ne voulez pas perdre des heures à rendre votre vidéo juste pour réaliser que quelque chose est foiré en raison d'un bug de rendu GPU. Si vous décidez de l'utiliser de toute façon, vous ne pouvez pas blâmer l'éditeur de logiciels - c'était votre décision.