Discussion :

[nyaman]

Bonjour,

Je cherche un outils permettant de voir le taux d'occupation du GPU lors d'une lecture de vidéos utilisant les possibilités DXVA de la carte.
Mon but est de voir à partir de combien de lecture paralèlle de flux MPEG2 ma carte graphique sature.

J'ai un processeur 8 cores : lorsque j'essais de lancer plusieurs lectures MPEG2 en paralèlle, le taux d'occupation augmente à chaque fois que lance une lecture supplémentaire mais ce taux d'occupation plafonne à 30% à partir de certain nbre de flux ajouté.

J'en conclu que l'accélération DXVA est le goulot d'étranglement. Pourquoi lorsque le GPU est saturé le traitement du décodage n'est pas attribué au CPU vu qu'il reste encore 70% de temps disponible ?

[LeGreg]

Il n'y a pas à ma connaissance d'outils qui permettent de voir l'occupation du GPU (enfin pas d'outil disponible au public).

J'en conclu que l'accélération DXVA est le goulot d'étranglement. Pourquoi lorsque le GPU est saturé le traitement du décodage n'est pas attribué au CPU vu qu'il reste encore 70% de temps disponible ?

Peut-etre parce que le load balancing CPU/GPU est encore un beau rêve ?

Ou peut-être parce que le logiciel de rendu de vidéo est optimisé pour un scénario précis (minimisation du temps CPU pour la lecture d'une seule vidéo et utilisation multi-tâche CPU de l'ordinateur) ? Et que les scénarios hypothétiques ne sont que peu d'intérêt ?

LeGreg

[nyaman]

Après plus d'analyses, je me rend compte que le problème n'est peut-être pas ce que je pensais.
Lorsque j'ouvre plusieurs instances de mon application (chacune jouant 1 vidéo MPEG2), le taux d'utilisation de mon CPU monte comme il faut et les vidéos jouent fluidement (jusqu'à une dizaine ça marche bien sans ramer).

Par contre lorsque je lance une instance de mon appli et que celle-ci joue plusieurs vidéos (donc la même appli construit plusieurs graphes directshow) alors au bout d'un certain nombre de vidéos (4 ou 5) les vidéos ne sont plus fluides du tout et côté taux CPU et taux lecture disque je plafonne a des valeurs bien inférieures à quand il y a plusieurs instances de l'appli.

D'après les informations que j'ai, les filtres des graphes directshow effectuent leur traitements dans des worker thread, c'est pourquoi j'ai pensé qu'en faisant la construction de tous mes graphes dans le thread principal de l'application ça ne causerait pas de pb.
Pensez-vous que mon pb de perfs puisse provenir du fait que chaque graph n'est pas construit dans un thread séparé ?

[nyaman]

Ou peut-être parce que le logiciel de rendu de vidéo est optimisé pour un scénario précis (minimisation du temps CPU pour la lecture d'une seule vidéo et utilisation multi-tâche CPU de l'ordinateur) ? Et que les scénarios hypothétiques ne sont que peu d'intérêt ?

Le logiciel de rendu à l'écran est le filtre VMR7 de directshow, il est dans un graphe construit par ma propre application.
Le mode de rendu est le Windowsless : chaque flux s'affiche dans une CWnd que je crée dynamiquement à l'ouverture du fichier et qui est CHILD de la CDialog principale.

[moldavi]

Bonjour.

A ma connaissance, je ne pense pas que le décodage mpeg2 par les composants de la majorité des cartes graphiques soit multithreadé. En ce sens qu'une seule vidéo à la fois peut bénéficier de l'accélération matérielle.

D'ailleurs avec XP et vmr7/9 je suis presque certain que non. Lorsque je lance deux mpeg2 en même temps avec la vrm9, je n'ai pas le même jeu de couleur pour les deux vidéos...

Sous Vista et avec Evr, à voir mais je n'ai pas fait suffisamment de test. Le décodage mpeg2, HD, semble faire maintenant parti des cartes graphiques récentes mais rien qui certifie que c'est multithreadé. D'ailleurs mis à part avoir les sources du filtre qui utilise l'accélération matérielle, c'est impossible de savoir ce qui se passe dans la carte graphique.

De plus, il n'y a pas si longtemps, les CG étaient estampillées DXVA et blabla, mais les drivers ne permettaient pas de les utiliser... Fallait attendre que ceux-ci sortent.

Tous ceci est en phase de développement, grâce à l'engouement pour la HD, qui a montré à quel point les PC actuels ont du retard dans la lecture des formats vidéo. Ca changent mais ce n'est que le balbutiement : voir Cuda et les possibilités.

Par contre 4 vidéo au format mpeg2 me semble la limite avec les PC actuels. Tu as le problème des interruptions à gogo (accès disque, accès CG, accès audio, etc...). Avec un disque en IDE, ce n'est même pas la peine. Au final, tout devient limitant, et c'est bien là que l'on voit les limites des PC. C'est pas vraiment optimisé pour faire mumuse avec plein de vidéo. Et puis les fabricants ont longtemps préférés passer du shader 1 à la version 56... Mais niveau décodage vidéo, bah ça les intéressait pas trop. Pour t'en convaincre, regardes les specs de DXVA 1 et surtout les dates et les évolutions (LoL).

Sous Vista, avec l'EVR et DXVA2 (Cuda), c'est peut-être en train de prendre une tournure intéressante.

[nyaman]

Merci pour ta réponse.

Mon objectif est d'essayer de localiser où exactement ça coince dans la chaine de traitement (lecture disque? décodage mpeg2 ? fenêtrage MFC ? ).
Le pb est que quand je lance plusieurs application, chacune jouant 1 seule vidéo, ça passe bien mieux que quand j'essais de lire autant de vidéos mais dans une seule appli.
Pour l'instant j'implémente la solution de faire la construction de chaque graphe dans un thread séparé, on verra bien le résultat.

C'est un comble quand je vois que je peux lancer bien plus d'instances de VLC que de n'importe quel player basé sur DS.

[moldavi]

Bonjour.

Je viens de faire l'essai sous Vista. Visiblement le jeu de couleur est identique donc les composants qui accélèrent la vidéo sont multithreadés (mais CG geforece 8).

Si je lance deux graphedits avec la même video, j'ai pratiquement le double d'occupation processeur, ce qui confirmerai ce que j'ai dit plus haut.

Lorsque je lance un seul graphedit avec deux videos, j'ai environ 7% d'occupation processeur en plus de la version avec 2 graphedits. Ceci confirme ce que tu dis à propos de deux videos dans une même application. Mais tout cela avec le default video renderer.

Par contre avec l'EVR, c'est presque pareil, pas vraiment de différence entre 1 et 2 graphedits.

Pas de conclusion particulière.