Brunni (./77) :
Zerosquare (./76) :
./72 : ben à mon avis ça tient surtout au fait qu'Aero n'est pas optimisé, parce que bon vu les effets... (un peu de flou, de zoom et de transparence, sur des petites zones de l'écran. En plus pour les barres de titre et la barre des tâches, ça n'a même pas besoin d'être recalculé à 60 fps constamment, mais seulement quand il y a des pixels qui changent dans cette zone)
En bref, non ce n'est pas ça. La 2D est juste complexe à réaliser pour un GPU 3D, pour pas mal de raisons (taille des textures, accès partagé au buffer, etc.). Tu serais étonné ^^
Effectivement, si tu passes par l'API 3D, afficher une scène en 2D n'est pas bien différent d'afficher une scène en 3D. Ça aura beau avoir l'air « tout pourri », ce n'est pas pour autant que tu utiliseras de quelconques fonctionnalités 2D.
Il y a toujours eu des fonctions graphiques 2D accélérées, mais je crois que ce sont des primitives utilisées à très bas niveau dans les systèmes, et auxquelles tu ne peux jamais accéder directement (mais indirectement, par exemple, avec GDI… ^^)
Je ne me suis jamais penché dessus (on verra le jour où je coderai mon propre OS), mais de ce que j'en ai toujours compris, le jeu de fonctions accélérées pour la 2D ne se recoupe pas nécessairement avec les fonctionnalités 3D de la carte. (Par exemple, les « layered windows » n'ont jamais été correctement accélérées sous Windows. Avoir un GPU capable de t'afficher une scène transparente en plein écran ne te garantissait pas que les fenêtres se déplacent de manière fluide…)
Enfin bref, techniquement, pour afficher une scène en 2D par l'API 3D, tu dois passer par tout le pipeline 3D qui fait intervenir des shaders, mêmes bidons (c'est obligatoire sur toutes les cartes modernes puisque le fixed function pipeline a complètement disparu de leurs transistors), différentes unités de texturing, etc… et qui accapare toutes les unités de traitement de la carte graphique (comme ça c'est plus rapide)… Une scène 2D peut consommer tout autant voire plus de fillrate qu'une scène 3D, surtout qu'on n'utilise pas forcément le Z-Buffer dans ce cas là (enfin même plutôt pas du tout la plupart du temps, même si ça reste envisageable)
Enfin en gros pour imager, afficher une pyramide texturée en 3D devrait consommer moins, ou, dans le pire des cas, autant de ressources qu'afficher 2 rectangles texturés à l'écran (1 rectangle = 2 triangles…)
Quand à Aero, moi je trouve justement qu'il est plutôt bien optimisé… (Y'a qu'à voir qu'en 1920x1080 il peut afficher le bureau de manière très fluide et sans surchauffer, le tout en faisant tourner une appli 3D légère et/ou WPF)
Après j'avais déjà du en toucher un mot, mais un flou gaussien (même séparé en deux passes) n'est pas vraiment « léger » en performances (c'est plutôt l'inverse). De même, la transparence n'est pas gratuite comme on semble le penser. Pour calculer la couleur finale d'un pixel, tua s besoin de la couleur précédemment dans le frame buffer, donc au lieu d'une seule écriture, tu as en réalité besoin d'une lecture suivie d'une écriture. Si ton pixel doit être le résultat d'un mélange de 7 pixels, il compte comme 7 pixels (pareil si c'était un pixel opaque en fait), mais est potentiellement (hors optimisations) deux fois plus coûteux (14 accès mémoire) que le même pixel s'il avait toujours été rendu en opaque. (7 accès mémoire)
À cause de ça, les opérations d'accès aux pixels doivent être synchronisées, et tu ne peux pas procéder à toutes les optimisations qu'un rendu opaque te permettrait. (Je pense à des optimisations théoriques, genre paralléliser le dessin de deux pixels superposés (si le pixel "supérieur" finit son dessin avant, tu annules l'autre, etc…), aucune idée de si c'est appliqué concrètement, mais c'est dans le genre des optimisations qui sont appliqués dans une carte graphique (éventuellement avec l'aide des drivers))
Sans compter bien sûr que tu dois ordonner ton dessin (pour afficher un écran comme DWM sous Windows de toutes façons, ça l'est forcément), et que le Z-Buffer ne sert quasiment à rien dans ce cas… (Pour cette raison, on conseille de dessiner en premier lieu les objets opaques, puis ensuite les objets transparents, puis enfin les particules ou assimilables)
Enfin, bref, l'alpha blending est gourmand en fillrate… Le flou gaussien est un calcul gourmand… Aero s'en tire pas mal, même sur les configurations à base de chipset intel (merdique) GMA…
Après, un outil du système tel que le DWM de Windows est un peu au delà de la séparation 2D 3D, et il y a tout un tas de fonctionnalités bas niveau (accessibles via le driver graphique) qui entrent en jeu, et qui ne sont pas directement (ou pas du tout) accessibles à des API de haut niveau comme GDI ou Direct3D/OpenGL… Mais là c'est un peu trop complexe pour moi (j'ai toujours voulu connaître un peu plus de détails, mais jamais vraiment pris le temps… Et puis je crois que je serais obligé de lire la source d'un driver graphique linux open-source pour ça
)
Enfin bref, c'est plus un aspect système qu'un aspect graphique, et là, si quelqu'un ici a des détails (l'interaction entre les parties 2D/3D), je suis preneur… ^^
(Il y a des API bas niveau pour ça dans Windows, mais je pense que les plus intéressants ont des points d'entrée anonymes)
[/blabla]
Folco > Je compatis pour ton problème de carte graphique.
En tout cas maintenant que j'ai vu ce topic je comprends mieux la question que tu m'as posée avant-hier
Bonne chance pour ton opération de la dernière chance ^^
(Et désolé pour le pavé dans ton topic
)
)
)
