Share
Les pipelines à fonction fixe n’ont plus d’affaires sur nos cartes vidéo. Voici ce que vous devez savoir sur eux et comment les écarter, si vous ne l'avez pas encore fait..
Il était une fois, quand le développement de jeux (ou le codage de tout ce qui avait trait aux graphiques en temps réel) était limité à l'écriture sur une matrice relativement petite d'intensités de couleurs (les tampon d'image) et en l'envoyant au matériel, vous pouvez faire ce que vous voulez avec. Vous pouvez dessiner à l'image une, dix ou cent fois. Vous pouvez passer à nouveau sur le frame buffer pour créer des effets nets. En bref, quelle que soit la capacité de votre processeur, vous pouvez le faire pour l’image envoyée au moniteur. Cela vous permettait de faire des choses vraiment géniales et créatives, mais les gens ne les utilisaient jamais (ou rarement) à ce point. Mais pourquoi?
La réponse: parce que c'était lent. Une image de 640 × 480 pixels (résolution courante à ce moment-là) contient 307 200 pixels. Et les processeurs étaient tellement plus lents que vous ne pouviez pas faire grand chose dans le court délai imparti pour dessiner ce cadre. Après tout, si vous souhaitez continuer à dessiner à 30 images par seconde, vous n’avez qu’environ 30 ms pour mettre à jour votre logique de jeu et l’affichage à l’écran, ce qui doit inclure les frais généraux liés à l’intercommunication avec le matériel. Ce n'était pas beaucoup.
Puis vint le GPU cool avec pipelines de rendu. En tant que développeur, vous vous chargez de mettre à jour la logique du jeu et d'envoyer vos textures et vos triangles au GPU, ce qui vous évitera de perdre du temps. Ceux-là étaient pipelines de rendu à fonction fixe (FFP): ce qui signifie que vous ne pouvez pas configurer le les fonctions ils ont joué. Vous pouvez leur dire "faites le brouillard gris foncé" ou "ne faites pas l'éclairage pour moi!" et vous pouvez configurer beaucoup de l'autre paramètres, mais le les fonctions eux-mêmes sont restés.
Le matériel était câblé et étroitement spécialisé, de sorte qu'il effectuait certaines opérations standard sur vos données. Et comme il était câblé de cette façon, c’était bien plus rapide que de le faire sur votre processeur. Mais un inconvénient était que vous payiez beaucoup pour cette vitesse: vous payiez en souplesse. Mais si vous avez toujours voulu dessiner quelque chose de complexe, le processeur n'était tout simplement pas assez rapide et la soumission de vos sommets au GPU était le seul choix..
C’est à peu près ainsi que fonctionnait le pipeline à fonction fixe. L'image n'est pas conçue comme une représentation précise, mais pour vous donner un indice sur la façon dont tout cela s'est déroulé.Le monde graphique évoluait encore rapidement. Comme tous les gens créatifs et talentueux, les développeurs de jeux aiment les défis, et l’un des la Les défis pour eux ont été (et resteront!), pendant longtemps, de rendre des images réalistes toujours plus belles.
Le pipeline à fonction fixe fournissait quelques fonctionnalités intéressantes, telles que plusieurs modes de fusion, l’ombrage Gouraud par sommet, les effets de brouillard, les tampons de gabarit (pour les volumes d’ombre) et autres, de sorte que les développeurs utilisaient ce qu’ils pouvaient. Bientôt, il y avait des effets vraiment impressionnants, tous en vertu de phénomènes réels simulés en utilisant quelques astuces bon marché (enfin, bon marché par rapport aux normes actuelles).
Tout se passait très bien, mais il restait limité par le nombre de fonctions que pouvait jouer le pipeline fixe. Après tout, le monde réel contient une multitude de matériaux différents et, pour les simuler, la seule variation qu’ils étaient autorisés à effectuer était de changer certains modes de fusion, d’ajouter des textures supplémentaires ou d’ajuster les couleurs de réflexion de la lumière..
Puis c'est arrivé: les premiers GPU programmables sont arrivés. Ils ne sont pas venus du jour au lendemain, bien sûr, et ils devaient arriver un jour, mais cela suscitait encore l'excitation. Ces GPU avaient ce qu’on appelait une pipeline de rendu programmable: vous pouvez maintenant écrire des programmes, appelés shaders, dans un langage d'assemblage limité, et les faire exécuter pour chaque sommet ou fragment, sur la carte vidéo. Ce fut un grand bond en avant, et ça allait de mieux en mieux.
Bientôt, les langages d'assemblage ont augmenté en complexité et en expressivité, et des langages de haut niveau pour la programmation GPU ont émergé, tels que HLSL, GLSL, et plus tard Cg. Aujourd'hui, nous avons des shaders de géométrie qui peuvent même émettre de nouveaux sommets, ou des shaders qui contrôlent de manière dynamique la tessellation et les triangles tessellés. À l'intérieur, nous pouvons échantillonner une quantité incroyable de textures, relier de manière dynamique et faire toutes sortes de calculs fous sur les valeurs d'entrée..
Lorsque vous donnez ces avantages aux développeurs, ils se déchaînent. Bientôt, ils écrivaient des shaders pour toutes sortes de choses: mappage de parallaxe, modèles d'éclairage personnalisés, réfraction, etc. Plus tard, même des systèmes d'éclairage totalement personnalisés ont émergé, tels que l'ombrage différé et le pré-passage de la lumière, et vous avez pu voir des effets complexes de post-traitement tels que l'occlusion ambiante de l'espace écran et l'occlusion ambiante basée sur l'horizon. Certains "abusaient" même des shaders pour effectuer des tâches répétitives et lourdes en mathématiques, comme le traitement statistique ou la rupture de hachages de chaînes. (C'était avant que l'informatique à usage général sur les GPU ne reçoive le support habituel.)
En bref, l’infographie a explosé avec l’introduction des shaders, et pour cause: la possibilité de programmer ce qui est arrivé aux vertices, fragments, textures, etc., et de le faire. vite, fourni des possibilités presque infinies.
Une représentation simplifiée du pipeline programmable. Notez comment les étapes spécifiques de transformation, d'ombrage ou de texture ont été remplacées par des shaders spécialisés. (Tessellation omise pour plus de clarté.)Bientôt, les pipelines à fonction fixe étaient obsolètes, du moins pour les développeurs de jeux. Après tout, pourquoi s'embêter avec de tels jardins murés quand vous pouvez programmer avec précision ce qu'il advient de vos données? Ils sont restés utilisés beaucoup plus longtemps dans certaines applications où le réalisme n’était pas un problème, comme pour la CAO. Mais dans l'ensemble, ils étaient ignorés.
OpenGL ES 2.0, publié en 2007, déconseillait ou supprimait son pipeline à fonction fixe au profit d'un pipeline programmable. OpenGL 3.2, en 2009, a finalement supprimé toute notion de traitement de vertex et de fragment à fonction fixe (cependant, il reste disponible pour une utilisation héritée via profil de compatibilité). Il est clair qu’aujourd’hui, il est peu logique de travailler avec le pipeline limité, alors que vous disposez de puissants GPU capables de vous permettre de réaliser d’impressionnantes choses..
Étant donné que ces API vous obligent à utiliser des shaders (notamment DirectX, qui ne supprime pas explicitement la fonctionnalité, inclut des outils facilitant la migration depuis l'ancienne approche et ne contenant pratiquement aucune nouvelle documentation concernant FFP), il est difficile de les obtenir correctement. pour un débutant. Si vous ne faites que commencer en tant que débutant en programmation 3D, il est beaucoup plus facile de dire à l'API vos matrices, paramètres d'éclairage, etc., et de tout faire à votre place..
Mais à long terme, cela vous sera beaucoup plus bénéfique si vous apprenez à écrire des programmes décrivant précisément le processus. Vous comprendrez très bien ce qui se passe sous le capot, vous comprenez certains concepts très importants que FFP ne vous oblige pas à maîtriser et vous êtes en mesure de modifier très facilement vos documents pour faire quelque chose de complexe que la fonction fixe ne peut jamais faire pour vous (et cela est utile. pour le débogage aussi!).
J'ai mentionné OpenGL ES, et permettez-moi de développer cela plus en détail. Alors que les jeux sur mobile deviennent de plus en plus populaires, il est logique de créer des mondes virtuels de plus en plus complexes. La plupart des appels à fonction fixe ont été supprimés dans ES 2.0 (ce qui signifie naturellement qu'ils sont également absents des versions suivantes). Cela signifie essentiellement que, pour utiliser l’une des fonctionnalités après ES 1.1, vous devez utiliser des shaders..
ES 2.0 est pris en charge par les iPhone depuis 3GS, les iPad depuis la première version et les appareils iPod Touch de génération 3 et plus. Qualcomm Snapdragon, une puce largement utilisée dans la production de téléphones Android, prend également en charge OpenGL ES 2.0. C'est très large support, car ES 2.0 n’est pas exactement "nouveau": il a plus de 7 ans maintenant. Pour tirer le meilleur parti de ces architectures, vous devez abandonner le pipeline à fonction fixe.
Je suppose que la plupart d'entre vous l'ont déjà fait il y a très longtemps, mais je n'ai pas eu beaucoup de mal à imaginer des moteurs graphiques 2D ou des jeux traditionnels qui utilisent encore des fonctions fixes (car il n'en faut pas davantage). Tout va bien, mais l'utiliser pour de nouveaux projets, ou former des programmeurs, semble être une perte de temps. Cela est amplifié par le fait que de nombreux didacticiels que vous pouvez trouver sur Internet sont totalement obsolètes et vous apprendront à utiliser le FFP dès le début. Avant même de vous rendre compte de ce qui se passe, vous serez au plus profond de vous..
Mon premier pinceau avec des graphiques 3D était un ancien tutoriel de DirectX 7 écrit en Visual Basic. À ce moment-là, l’utilisation du pipeline à fonction fixe était généralement logique, car le matériel n’était pas suffisamment avancé pour offrir la même fonctionnalité avec des shaders au même débit. Mais aujourd'hui, nous constatons que les API graphiques commencent à abandonner ou à déconseiller fortement la prise en charge de cette dernière, et cela ne devient en réalité qu'un artefact du passé. C'est un bon artefact utile qui nous rend nostalgiques, mais nous devrions rester à l'écart. Il est vieux et n'est plus utilisé.
Ces douces réflexions et réfractions de Fresnel, générées par une démonstration d'OGRE (Open-source Graphics Rendering Engine), n'auraient jamais pu être réalisées si vous vous en teniez aux méthodes préconisées dans les anciens tutoriels DirectX 8 ou OpenGL 1.1..Si vous êtes intéressé par le développement de jeux sérieux, vous en tenir au pipeline à fonction fixe est un vestige du passé. Si vous envisagez de vous lancer dans les graphiques 3D, mon conseil (et celui de beaucoup, beaucoup de développeurs) est simplement de l'éviter..
Si vous voyez passer des positions d’éclairage à l’API graphique (pas en tant que paramètre shader), ou des appels de fonction API tels que glFogv, courir comme le vent et ne pas regarder en arrière. Il existe un nouveau monde de GPU programmables, qui existe depuis longtemps. Tout le reste perd probablement votre temps.
Même si vous n'aimez que les graphiques 2D, il est toujours sage de ne plus vous fier à FFP. (Bien sûr, tant que vous ne supporterez pas du matériel ancien.) Les shaders peuvent vous fournir d’excellents effets ultra-rapides. Le flou, la netteté, les grilles de chaîne, le rendu vectoriel et la simulation physique ou à grande échelle de particules peuvent tous être réalisés sur le GPU, et peuvent tous profiter aux jeux 2D et 3D..
Alors, encore une fois, mon conseil, même si vous n’allez pas explicitement apprendre le développement de jeux 3D, est d’apprendre à écrire des shaders. C’est amusant de travailler avec, et je vous garantis que vous allez passer de nombreuses heures amusantes à perfectionner un effet de shader cool: un skybox dynamique, une peinture de voiture ou un mappage d’ombres divisé en parallèle, ou tout ce que votre cœur désire. Du moins, c’est ce qui m’est arrivé: une fois que vous êtes habitué à utiliser le pipeline fixe à cause de certaines limitations (comme j’étais obligé de le faire, afin d’obtenir des performances acceptables sur mon 5200FX), la programmation du GPU est une tâche ardue. souffle, et des tas de plaisir.
J'espère avoir expliqué à ceux pour qui le choix n'était pas clair, comment fonctionnait le graphisme 3D il y a longtemps et comment cela fonctionne maintenant, et j'espère avoir convaincu le petit nombre d'entre vous qui étaient sur le point de suivre les didacticiels NeHe ou Swiftless sinon, allez voir quelque chose de plus moderne. Comme toujours, j'ai peut-être commis des erreurs, alors n'hésitez pas à les signaler dans les commentaires. Jusqu'à la prochaine fois!
Accentsconagua