Silverlight 3 : précisions sur l’accélération matérielle GPU

Avec la sortie de la Beta de Silverlight 3, l’utilisation de l’accélération matérielle via le GPU (le processeur de votre carte graphique) est désormais possible au sein d’une application Silverlight. Le GPU (Graphics Processing Unit) est bien connu par les gamers et s’occupe en général d’effectuer des opérations de calculs flottant spécifiques, de gérer les scènes 3D, les effets graphiques (Pixel & Vertex Shaders), etc. Par ailleurs, il contient également un certain nombre de primitives graphiques pouvant économiser beaucoup de temps CPU. Ces dernières puces sont désormais tellement évoluées qu’elles peuvent même supporter la notion de Geometry Shaders sous DirectX 10. Enfin, bref, on s’écarte du sujet… :)

L’idée est donc de faire usage de cette puissance disponible et spécialisée pour soulager le CPU sur certaines tâches du rendu graphique.

Par défaut, l’accélération matérielle est désactivée. C’est quelque chose qui sera peut-être revue dans la version finale de Silverlight 3. Cependant, pour l’heure actuelle, vous devez indiquer au plug-in Silverlight que vous souhaitez l’utiliser et vous devez également préciser certaines choses au niveau des contrôles.

Pour l’activer au niveau de la runtime, ouvrez la page web hébergeant votre application Silverlight.

Pour un hébergement dans une page HTML, voici la modification à faire:

<param name="EnableGPUAcceleration" value="true" />

Pour un hébergement au sein d’une page ASP.NET, ajoutez l’attribut suivant:

<asp:Silverlight ID="Silverlight1" EnableGPUAcceleration="true" runat="server" Source="~/ClientBin/MonAppliSL3.xap" MinimumVersion="3.0.40307.0" Width="100%" Height="100%" />

Ensuite, pour en faire usage au niveau de votre contrôle, voici un exemple d’utilisation:

<Canvas x:Name="LayoutRoot" Width="800" Height="600" >
        <Canvas.CacheMode>
            <BitmapCache/>
        </Canvas.CacheMode>
</Canvas>

Actuellement, l’utilisation de BitmapCache représente votre unique option. Cela demande alors à la runtime Silverlight 3 de mettre en cache sous forme d’une bitmap (image donc) le rendu d’un élément visuel et de ses enfants. Ainsi, une fois mise en cache, votre application n’essaiera plus de passer par la phase de rendu, couteuse en performance, de vos éléments cachés et s’occupera simplement de les afficher. Sauf bien sûr, si ces derniers ont changé.

A des fins d’analyses ou debugging, si vous souhaitez savoir ce qui est mise en cache par Silverlight de ce qui ne l'est pas, ajoutez les attributs suivants à votre page d’hébergement:

<asp:Silverlight EnableCacheVisualization="true" ID="Silverlight1" EnableGPUAcceleration="true" runat="server" Source="~/ClientBin/MonAppliSL3.xap" MinimumVersion="3.0.40307.0" Width="100%" Height="100%" />

Une fois ces options activées, relancez votre application. Vous verrez alors apparaître les objets non cachés tintés d’une couleur précise, les objets cachés restant rendus à l’identique (aucune tinte donc).

Je rappelle également que l’accélération matérielle est disponible pour les machines sous Windows à la fois en plein écran et en mode fenêtré, et également disponible sur plateforme Mac en plein écran seulement pour l’instant.

Pour la petite histoire, j’avais demandé à l’une des charmantes responsables de cette partie de Silverlight à Microsoft Corp les détails d’implémentation. DirectX est utilisé sur PC Windows pour le support de l’accélération et OpenGL sur Mac.

Nous lui avions également posé la question pour connaître les raisons les ayant poussés à désactiver cette fonction par défaut. La réponse est: la mise en place du caching d’éléments permet effectivement une amélioration des performances du rendu graphique mais forcément au détriment de l’utilisation mémoire. Or, ils considéraient que tous les scénarios ne se prêtaient pas forcément à l’accélération matérielle.

Voici les cas où l’on conseille d’activer cette accélération:

1 – L’utilisation de transformations : translation, rotation, mise à l’échelle, etc.
2 – Clipping
3 – Blending

Un des exemples les plus évidents est la mise à l’échelle d’une vidéo HD (ou non d’ailleurs) à la résolution de l’écran. En effet, imaginez une vidéo de 800x600 que l’on met en plein écran sur une dalle LCD full HD (1920x1080), cela demande beaucoup de sollicitation du processeur. Si en plus, c’est une vidéo au format H264, cela demande également beaucoup de temps CPU (ce codec étant particulièrement gourmant). Donc, il est bien sûr préférable de transférer le maximum d'opérations vers la carte graphique très alaise dans ce domaine et laisser en paix notre CPU préféré pour qu’il s’adonne à d’autres tâches (le moteur physique par exemple ! ;-)). Note: dans Silverlight 3, le GPU n'est pas sollicité pour la décompression vidéo (H264, VC1 ou WMV).

Pour le reste, il faut choisir des éléments à cacher relativement statiques. C’est assez logique: si l’élément est peu susceptible d’évoluer au niveau de son rendu graphique pendant la vie de l’application, c’est un bon candidat au caching hardware (fond d’écran par exemple). Si l’élément propose un rendu très dynamique, évitez de le mettre en cache, cela ne servira à rien et occupera vos ressources mémoire pour rien.

Note sur les Pixel Shaders :  je rappelle que, contraitement à WPF 3.5 SP1, Silverlight 3 ne gère pas les pixel shaders de manière matérielle avec le GPU. On dit ainsi qu'ils sont gérés de manière "software" par le CPU (même si le CPU représente du hardware...). Ainsi, le fait de mettre en place un effet shader sur un élément caché désactive defacto l'accélération hardware sur ce même élément.

Pour terminer, voici un ensemble de ressources que je vous conseille sur ce sujet:

1 – La charmante responsable dont je vous parlais s’appelle Seema Ramchandani et vous pouvez la retrouver sur son blog: https://blogs.msdn.com/seema/ . Transfuge de l’équipe en charge de WPF, elle travaille désormais dans l’équipe Silverlight et assure grave coté GPU. Bref, vive les womens in IT !

Ainsi, si vous désirez en savoir davantage sur la manière dont l’arbre graphique de Silverlight 3 est géré, je vous conseille ainsi de suivre une de ses sessions du MIX09 à laquelle j’ai eu la chance d'assister : Deep Dive into Microsoft Silverlight Graphics.

2 – Si vous souhaitez vous rendre compte en action des différences de performance avec et sans l’accélération matérielle activée dans un scénario où cela fait sens:

Sans l’accélération matérielle activée: https://www.andybeaulieu.com/silverlight/3.0/scrollmonster/DisabledGPUAcceleration.html

Avec l’accélération matérielle activée: https://www.andybeaulieu.com/silverlight/3.0/scrollmonster/EnabledGPUAcceleration.html   

Dans mon cas, je passe de 10-15 FPS (Frames Per Second/Images par seconde) à 45/50 FPS avec 25 singes affichés en même temps. Un gain de plus de 300% !

Vous pouvez télécharger le code source de cette démo et obtenir davantage d’informations sur le sujet ici.

David

Comments

• Anonymous
  April 27, 2009
  Tiens, chez moi, en mettant 25 singes et en activant la rotation + le scaling, j'obtiens :

• Entre 15 et 30 FPS lorsque l'accélération est désactivée.
• 60 FPS, fixes, lorsqu'elle est activée. Le gain de performance va donc directement dépendre - et ce n'est pas vraiment surprenant - de la carte graphique.

• Anonymous
  August 03, 2009
  En complément on peut aussi voir cet excellent billet de Andras Velvart sur le sujet (en anglais): http://dotnetslackers.com/articles/silverlight/Discovering-Silverlight3-Deep-Dive-into-GPU-Acceleration.aspx

• Anonymous
  August 21, 2009
  Je pensais pas que le gain serait si important ! On tourne entre 300 et 500% de performance ! C'est ahurissant :O Est-ce que tu penses que ça peut être profitable d'utiliser l'accélération gpu pour un splash screen gourmand ? ou pour quelque utilisation de pixelshader dans l'application ? Du genre de celle que tu as fait avec l'image qui swich entre les pingouins et les fleurs ? merci pour le billet !

• Anonymous
  August 24, 2009
  Salut nk54, Comme je l'ai indiqué dans les 2 posts, les pixel shaders ne sont pas gérés pas le GPU en Silverlight 3. Par ailleurs, le simple fait de mettre en place un effet de shader te fait perdre l'accélération GPU sur l'élément en question. Bye, David