Article d'origine :
https://fr.dolphin-emu.org/blog/2017/07/30/ubershaders/
traduction via DeepL (merci le rebelle
)
Ubershaders: une solution ridicule à un problème impossible
Quand vous jouez votre jeu favori sur Dolphin avec un ordinateur puissant, les choses devraient fonctionner assez bien. Le jeu tourne à pleine vitesse, il n' y a pas de pépins graphiques, et vous pouvez utiliser votre contrôleur préféré si vous le souhaitez. Pourtant, chaque fois que vous allez dans une nouvelle zone ou que vous chargez un nouvel effet, il y a un "bégaiement" très léger mais perceptible. Vous désactivez le framelimiter pour vérifier et votre ordinateur peut exécuter le jeu à une vitesse bien supérieure à la vitesse maximale. Qu'est-ce qui se passe?
Le ralentissement lors du chargement de nouvelles zones, effets, modèles et autres est communément appelé "Shader Compilation Stuttering", par les utilisateurs et les développeurs. Ce problème fait partie de Dolphin depuis le tout début, mais ce n'est que récemment qu'il est devenu plus important.
Quand les jeux étaient à peine lancés, un petit bégaiement ici et là n'était pas grand chose. Bien que l'émulation se soit améliorée jusqu' à devenir presque parfaite dans de nombreux titres, le bégaiement est resté le même au fil des ans. Depuis la sortie de Dolphin 4.0, les utilisateurs se plaignent en fait de la compilation des shaders qui bégaie de plus en plus rapidement. Bien qu'une partie de cela peut être partiellement due à l'augmentation des exigences GPU de nombre entier de mathématiques, la plus grande cause a été en fait que le bégaiement s'est démarqué plus avec il y a maintenant moins de problèmes graves autrement.
Il y a eu un peu de frustration et même de l'antipathie de la part des développeurs envers le bégaiement de la compilation des shaders. C'était quelque chose qui était considéré comme irréparable et qui suscitait beaucoup de mauvaise volonté et de frustration au sein de la communauté. Ironiquement, nous haïssions le bégaiement autant que n'importe qui d'autre, mais la folie pure et simple de la tâche était suffisante pour éloigner la plupart des développeurs. Malgré cela, certains ont gardé une lueur d'espoir. C'était au départ une théorie qui avait une chance de fonctionner. Une théorie qui nécessiterait des centaines, sinon des milliers d'heures-personnes pour voir si c'était possible.
C'est cet espoir qui a alimenté un voyage ardu contre des chances apparemment impossibles. Un voyage qui nécessiterait deux ans à plusieurs ingénieurs GPU. Le tout dans le but d'imiter la gamme complète du pipeline proto-programmable du GameCube/Wii sans être victime de ce bégaiement.
C'est l'aube de l'ère Ubershader.
Le problème
Les GPU modernes sont incroyablement flexibles, mais cette flexibilité a un coût - ils sont incroyablement compliqués. Pour débloquer cette puissance, les développeurs utilisent des shaders - des programmes que le GPU exécute tout comme un CPU exécute une application - pour programmer le GPU afin d'exécuter des effets et des techniques de rendu complexes. Devs écrivent du code dans un langage de shader à partir d'une API (comme OpenGL) et un compilateur de shader dans le pilote vidéo traduit ce code en binaires que le GPU de votre PC peut exécuter. Cette compilation prend de la puissance de traitement et du temps à compléter, donc les jeux PC modernes sont généralement contournés en compilant des shaders pendant les périodes où le framerate n' a pas d'importance, comme les temps de chargement. En raison du nombre de GPU PC différents, il est impossible pour les jeux PC de pré-compiler leurs shaders pour un GPU spécifique, et la seule façon d'obtenir des shaders à exécuter sur le matériel PC spécifique est pour les pilotes vidéo de compiler à un certain point dans le jeu.
Les consoles sont très différentes. Lorsque vous connaissez le matériel précis sur lequel vous allez exécuter le jeu, et que vous savez que le matériel ne changera jamais, vous pouvez pré-compiler les programmes GPU et juste les inclure sur le disque, ce qui accélère les temps de chargement du jeu et améliore les performances. Ceci est particulièrement important sur les anciennes consoles, qui n'ont peut-être pas assez de mémoire pour stocker les shaders en mémoire ou même la possibilité de les stocker. Flipper, le GPU GameCube, est ce dernier.
Bien qu'il dispose de certaines parties à fonction fixe, Flipper dispose d'une unité TEV (Texture EnVironment) programmable qui peut être configurée pour effectuer une grande variété d'effets et de techniques de rendu, de la même manière que les pixel shaders. En fait, l'unité TEV a des capacités très similaires à celles des shaders DirectX 8 pixels de la Xbox! Il était si flexible et puissant que Flipper a été réutilisé comme GPU Wii (redoublé Hollywood) avec peu de modifications. Malheureusement pour nous cependant, l'unité TEV est conçue pour que le jeu puisse configurer et exécuter des configurations TEV immédiatement lorsqu'un effet est nécessaire. Il n' y a pas de préchargement des configurations TEV, car l'unité TEV n' a pas la mémoire nécessaire.
Ce chargement instantané est la source de tous nos problèmes. Dolphin doit traduire chaque configuration Flipper/Hollywood qu'un jeu utilise en shader spécialisé que les GPU actuels peuvent exécuter, et les shaders doivent être compilés, ce qui prend du temps. Mais l'unité TEV n' a pas la capacité de stocker les configurations, donc les jeux GC/Wii doivent le configurer pour rendre un effet dès qu'il est nécessaire, sans délai ni préavis. Pour faire face à cette disparité, la seule option de Dolphin est de retarder le thread CPU pendant que le thread GPU et le pilote vidéo exécutent la compilation - essentiellement en mettant en pause l'émulation GC/Wii. Habituellement, la compilation se fera sous un cadre et les utilisateurs ne seront pas plus avisés, mais quand cela prend plus de temps qu'un cadre, le jeu s'arrêtera visiblement jusqu' à ce que la compilation soit terminée. C'est le bégaiement de la compilation des shaders. Typiquement, un bégaiement ne dure que quelques images, mais sur des scènes très exigeantes avec de multiples shaders de compilation, des bégaiements de plus d'une seconde sont possibles.
En tant que premier émulateur à émuler un système avec un GPU hautement programmable à pleine vitesse, Dolphin a dû faire cavalier seul pour résoudre ce problème. Nous avons implémenté la mise en cache des shaders donc si une configuration se produisait une deuxième fois, elle ne bégaierait pas, mais cela prendrait des heures de jeu pour construire un cache fiable, et un changement de GPU, une mise à jour du pilote du GPU ou même une nouvelle version de Dolphin invaliderait le cache et recommencerait à bégayer. Pendant des années, il semblait qu'il n' y avait rien de plus que nous pouvions faire contre le bégaiement des compilations de shaders, et beaucoup se demandaient si cela ne serait jamais résolu....
Résoudre un problème impossible
De tous les problèmes restants de Dolphin, le bégaiement des compilations de shader est le plus contesté. Qu'il s'agisse de l'information sur les dossiers, des forums, des médias sociaux ou de l'IRC, ce problème se pose tout le temps. Au fil des ans, la réaction a changé. Au début, ce bégaiement a été ignoré comme un problème non résolu. Qu'importe s'il y avait un léger bégaiement ici et là, si les matchs ne couraient pas du tout? Les choses ont changé en janvier 2015, lorsque ce bégaiement a été formellement accepté comme un bogue sur le traceur de problème de Dolphin, et la sensibilisation s'est répandue.
Au cours des dernières années, nous avons vu des utilisateurs poser de nombreuses questions sur le bégaiement des shaders, demander de l'action, déclarer l'émulateur inutile, et même certains développeurs de cuss dehors à cause du manque d'attention sur le bégaiement de la compilation des shaders. La vérité, c'est que nous haïssions le bégaiement autant que n'importe qui d'autre et que nous avions réfléchi au problème pendant de nombreuses années. Des tonnes de solutions avaient été envisagées, certaines même tentées. Il ne semblait pas possible de réparer sans effets secondaires graves.
Les solutions potentielles
Générez tous les shaders à l'avance!
Dolphin est assez rapide pour générer les shaders dont il a besoin, mais les compiler est un problème. Mais, si nous pouvions générer et compiler des shaders pour chaque configuration, cela résoudrait le problème, non? Malheureusement, ce n'est tout simplement pas possible.
Il y a environ 5,64 × 10 configurations potentielles de l'unité TEV seule, et nous aurions à faire un shader unique pour chaque configuration. Les shaders Vertex sont également utilisés pour émuler l'unité Hardware Transform et Lighting semi-programmable, ce qui augmente encore le nombre de combinaisons.
Même si nous pouvions les compiler, ces shaders ne seraient utilisables que sur la version de Dolphin sur laquelle ils ont été générés. La mise à niveau vers une nouvelle version nécessiterait un nouvel ensemble de shaders. D'autres occasions nécessaires comme la mise à jour de votre carte graphique ou la mise à niveau de vos pilotes graphiques nécessiteraient également une recompilation. Et tout cela repose sur le fait que le pilote dispose d'un cache de bas niveau, ce qui n'est pas le cas de tous les pilotes.
Prévoyez ce dont le jeu a besoin!
Si nous pouvions seulement générer et compiler des shaders pendant le chargement des écrans et ainsi de suite, il n' y aurait pas de bégaiement quand ça comptait. Essayer de prédire ce que le jeu veut faire n'est tout simplement pas faisable à un degré qui résoudrait ce problème. Les implications de performance et de mise en œuvre autour du fait que Dolphin essaye de "voir plus loin" soit en avançant rapidement et en prédisant le coût des intrants beaucoup trop élevé pour les situations qu'ils pourraient éventuellement aider.
La prédiction aveugle ne fonctionne pas non plus - un jeu peut choisir d'exécuter toutes les configurations qu'il veut sans aucun avertissement, et les configurations passées ne nous disent rien sur les configurations futures. Le seul moyen de savoir quels shaders un jeu aurait besoin serait de passer par un jeu et de découvrir toutes les configurations qu'il pourrait éventuellement vouloir.
... ce qui nous mène à la prochaine solution proposée.
Partager les Shaders
Dolphin utilise un objet "Unique ID", ou "UID" pour représenter une configuration du GPU émulé, et ces UID sont ensuite convertis en shader code et transmis au pilote vidéo pour compilation. Comme les UIDs sont antérieurs à la compilation et n'ont pas été conçus pour un GPU PC spécifique, ils sont compatibles avec n'importe quel ordinateur et peuvent théoriquement être partagés. Les utilisateurs appellent cela des "shaders de partage" et en théorie, si les utilisateurs partageaient des fichiers UID, ils pourraient compiler des shaders à l'avance et ne pas rencontrer de bégaiement. Actuellement, le backend vidéo de Vulkan possède déjà cette fonctionnalité, comme cela était nécessaire pour éviter les problèmes de cache des shaders sur certains pilotes.
Alors, pourquoi n' a-t-on pas cherché à étendre cette solution?
Le dauphin s'améliore encore. Si un correctif graphique est fusionné, il se peut que toutes ces UIDs doivent être rejetées.
Tous les jeux ne seront pas desservis. Alors que les jeux populaires peuvent se rapprocher des collections UID complètes, les personnes qui jouent à des pierres précieuses cachées ne recevront probablement pas d'aide.
Dans les tests, il y a très peu de chevauchements UID entre les jeux. The Legend of Zelda: The Wind Waker et The Legend of Zelda: Twilight Princess partagent une petite partie (15%) des configurations, mais elles fonctionnent toutes deux sur le même moteur de base. La plupart des jeux ont beaucoup moins en commun les uns avec les autres, de sorte que le partage des jeux populaires ne bénéficiera certainement pas aux jeux moins connus.
Les utilisateurs peuvent manquer plusieurs UIDs. Il y a un nombre presque illimité de configurations. Même 100% d'un jeu n'est pas une garantie que vous avez atteint toutes les configurations.
Les développeurs ont réfléchi à cette idée pendant un certain temps, mais la mise en place de l'infrastructure pour partager les UID et trouver une bonne façon de les distribuer s'est avérée être la source de plus de désaccords que de solutions. Bien que cela puisse éventuellement être utilisé pour améliorer une solution déjà opérationnelle, il ne s'agit pas d'une solution fonctionnelle en soi.
Compilation asynchrone des shaders
Popularisée par une fourchette, la compilation asynchrone des shaders est une solution créative au dilemme de la compilation des shaders. Tino s'est penché sur le problème plus comme certains jeux modernes de gérer la même question de devoir compiler dynamiquement de nouveaux shaders - quand vous frayer dans une nouvelle zone, parfois de nouveaux objets juste "pop" dans comme ils sont chargés. Il se demandait s'il pouvait réaliser quelque chose de similaire dans un émulateur et commença à réécrire comment les shaders étaient manipulés dans sa fourchette.
Le concept de compilation asynchrone des shaders modifie le comportement de Dolphin lorsqu'il n' y a pas de shaders cachés pour une configuration Flipper/Hollywood rencontrée. Au lieu de mettre le jeu en pause et d'attendre qu'un shader compile, il saute simplement le rendu de l'objet. Cela signifie qu'il n' y a pas de pause ou de bégaiement, mais certains objets peuvent être absents de la vue jusqu' à ce que le shader soit prêt.
Cela fonctionne bien pour certains jeux. Selon la façon dont le moteur du jeu élimine les objets en dessinant le monde, les objets qui tombent en dehors du champ de vision de la caméra ou qui ne couvrent que quelques pixels à l'écran peuvent encore être rendus. Dans ce cas, le fait d'ignorer le rendu de ces objets n'est guère perceptible. Cependant, selon le jeu, cela peut se traduire par le "pop in" décrit plus haut.
Une des choses que les utilisateurs se demandaient, c'est pourquoi Dolphin n' a pas du moins implémenté les shaders asynchrones de Tino comme une option pour combattre le bégaiement des compilations de shaders. En fin de compte, cela s'est tout simplement traduit par le fait que les gens qui auraient pu l'implémenter avec d'autres développeurs de base étaient contre cette solution. Ils y voyaient simplement un piratage informatique qui causerait beaucoup de faux positifs sur le traqueur d'enjeux et causerait des problèmes plus importants par la suite. Ces inquiétudes se sont avérées quelque peu valables lorsque vous réalisez que certains jeux ont besoin d'objets pour être rendus sur le cadre qu'ils s'attendent à être. Dans ce cas, les têtes Mii ne sont rendues qu'une seule fois dans le Framebuffer Embedded. Si la copie EFB est manquante à cause de la compilation Async Shader Compilation, les têtes Mii ne se présenteront pas pour le reste du jeu ou jusqu' à ce qu'elles soient régénérées.
Malgré ses défauts, les utilisateurs de la fourchette de Tino jurent par la compilation asynchrone des shaders. Pour tout ce qui ne va pas avec les shaders asynchrones, ils résolvent à tout prix le problème de la compilation des shaders. Les inconvénients étaient trop abrupts pour qu'il puisse être fusionné avec Dolphin master, mais cette solution a définitivement mis en lumière à quel point la compilation de génération de shaders était un gros problème. Le travail de Tino sur la compilation asynchrone des shaders nous a vraiment permis de savoir à quel point les utilisateurs se souciaient de ce problème, et a motivé l'équipe à trouver une solution plus complète.
La solution
Rédigez un interprète pour le pipeline de rendu GameCube/Wii dans Shaders et exécutez-le sur la carte graphique hôte
Parfois, l'une des meilleures façons de résoudre un problème impossible est de changer de perspective. Peu importe ce que nous avons essayé, il n' y avait aucun moyen de compiler des shaders spécialisés aussi rapidement que les jeux pouvaient changer les configurations.
Mais que faire si nous n'avons pas besoin de faire appel à des shaders spécialisés? L'idée folle est née d'émuler le pipeline de rendu lui-même avec un interpréteur qui fonctionne directement sur le GPU comme un ensemble de shaders monstre et flexible. Si nous compilons ces shaders massifs au démarrage du jeu, chaque fois qu'un jeu configure Flipper/Hollywood pour rendre quelque chose, ces "shaders superbes" se configureraient et le rendraient sans avoir besoin de nouveaux shaders. Théoriquement, cela résoudrait le bégaiement de la compilation des shaders en évitant complètement la compilation.
Cette idée est folle en tous genres, mais c'était aussi la première idée qui avait le potentiel de résoudre ce problème impossible. La difficulté de cette solution réside plutôt dans l'absurde quantité de travail et d'expertise qu'il a fallu faire pour en arriver au point d'essayer. Pour le mettre en perspective, même parmi tous les développeurs qui travaillent sur Dolphin, seuls deux ou trois personnes au maximum ont les connaissances nécessaires non seulement sur le matériel GameCube/Wii, mais aussi sur les GPU, API et pilotes modernes pour écrire, déboguer et optimiser les shaders. Sans parler de l'utilisation d'un interpréteur comme shaders énormes n'est pas exactement facile sur le GPU, et beaucoup craignaient que tout ce travail pourrait même ne pas fonctionner à pleine vitesse sur les cartes vidéo actuelles.
Des centaines, voire des milliers d'heures de travail répétitif, mais difficile, ont été nécessaires sans garantie de gain.
Ce n'est qu'en 2015, lorsque le Phire est devenu si frustré par la compilation de shaders bégayant sur son tout nouvel ordinateur qu'il a fait une proposition et conçu le framework d'un ubershader. Bien qu'il était bien conscient des difficultés, il semblait déterminé à prouver que les Ubershaders étaient la solution à ce problème si ancien. phire y est allé tout seul dans une tentative d'enseigner à Dolphin comment rendre à nouveau.
Après avoir passé plus d'un mois à meuler sur le long métrage, il a réussi à faire en sorte que le pixel Ubershaders soit au point où certains jeux ont commencé à ressembler à leurs équivalents de shaders rapides. Ce qui est surprenant, ce n'est pas que ça ait marché, mais que le prototype Ubershaders ait fonctionné à plein régime. phire lui-même se souvient que sa réaction initiale consistait en, Holy shit, il tourne à pleine vitesse et admet en outre que les GPU ne devraient pas vraiment être en mesure de les exécuter à des vitesses jouables, mais ils le font. Malgré toutes les chances qu'ils avaient contre eux, les prototypes ont prouvé que les Ubershaders pouvaient être notre solution pour le bégaiement de la compilation des shaders. Et ainsi, le broyage a commencé à améliorer la précision des Ubershaders, à corriger les nombreux bugs et à implémenter les fonctionnalités manquantes.
L'effort pour même obtenir Ubershaders à l'extrême gauche du Phire complètement épuisé par le projet. En plus de cela, Phire a dû mettre une tonne de travail à nettoyer d'autres projets pour la sortie de Dolphin 5.0. Les retards se sont révélés coûteux, car il a perdu son feu pour continuer à travailler sur les Ubershaders grâce à l'épuisement professionnel et aux inquiétudes croissantes concernant les limitations des pilotes et de l'API concernant la solution. Bien qu'environ 90 % des travaux aient été achevés, les derniers 90 % restaient encore à faire, y compris certains aspects clés.
- Finition du sommet Ubershaders
- Infrastructure/lien pixel et sommet Ubershaders
- Résolution des problèmes de performance OpenGL et (après rebasage) Vulkan
- Nettoyage, correction de bugs et rendu identique aux shaders spécialisés
- Options GUI
- Optionnel - Mode hybride pour les GPU intégrés/faibles
Les voir sur le point de travailler était douloureux. Mais, il n' y avait pas de développeurs capables de travailler dessus avec la volonté d'entreprendre un projet aussi massif. Même ceux qui auraient pu envisager d' y travailler n'étaient pas prêts à s'occuper des travaux de nettoyage, des corrections de bogues et des travaux d'infrastructure. Pendant plus d'un an, les Ubershaders sont restés assis et ont mordu sur l'arrière-plan au milieu d'une liste toujours croissante de caractéristiques qui n'ont jamais été terminées, et l'espoir a recommencé à s'estomper....
Ubershaders 2.0
Shader compilation stuttering compilation est l'un des plus plaints des bugs de Dolphin, donc après le développement d'Ubershaders arrêté, les gens ne l'ont pas oublié. La demande de pull, bien que longtemps abandonnée, a quand même vu des commentaires, s'est mise en relation autour des forums et même postée sur le bug tracker sous différentes formes.
Ubershaders a été le premier véritable espoir d'éliminer la compilation de shaders en bégaiement, et il a été encore mis en place sur une base mensuelle. Au contraire, les progrès réalisés n'ont fait qu'exacerber le désir de la communauté de trouver une solution. Après avoir beaucoup plaidé, supplié et fait chanter la coercition honnête, Stenzek reprit à contrecoeur le manteau des Ubershaders.
Avant même que Stenzek n'ait commencé à travailler sur Ubershaders, l'équipe a pris des décisions concernant la maintenabilité des backends graphiques. L'une de ces décisions, qui a suscité une réaction mitigée, voire négative, a été l'élimination de l'arrière-plan du D3D12. Contrairement au D3D9, nous n'avons pas subi de processus de dénigrement; nous l'avons éliminé une fois qu'il était évident que personne ne le maintiendrait.
Cette décision fut toutefois fortuite, car l'élimination de ce backend aida à rebâtir et à relancer les Ubershaders lorsque Stenzek était prêt à donner le meilleur de lui-même. Comme il était l'architecte du backend Vulkan de Dolphin, il était déjà tout à fait disposé à travailler sur Vulkan.
Quand le pixel et le sommet Ubershaders ont finalement été connectés ensemble et prêts pour une exécution, les testeurs les ont immédiatement emmenés à certains des pires scénarios. Considérant qu'aucune des solutions précédentes n' a vraiment fonctionné pour un jeu comme Metroid Prime 3, c'était d'abord sur le bordereau.
Le test initial d'Ubershaders a été un succès massif, avec le bégaiement complètement éliminé en D3D, et seulement quelques étranges bégaiements au début dans les exécutions dans OpenGL et Vulkan. La poursuite du travail sur Ubershaders a permis d'améliorer les choses dans chaque backend, à quelques exceptions près que nous noterons plus tard. Mais le seul fait de lancer des jeux sur Ubershaders n'était pas la fin du jeu; les Ubershaders purs sont une perte de performance massive sur la carte graphique hôte. Bien que les exigences de chaque jeu varient, votre carte graphique affectera grandement la résolution que vous pourrez utiliser. Avec une résolution interne de 1x (480p), la plupart des GPU dédiés devraient être capables de faire le travail, avec des cartes haut de gamme capables de pousser jusqu' à 1080p ou plus haut, en utilisant même exclusivement les Ubershaders. Malheureusement, beaucoup de nos utilisateurs n'ont pas le matériel nécessaire pour faire fonctionner Ubershaders à la résolution qu'ils préfèrent, ce qui les mettrait dans la position malheureuse de choisir entre résolution et fluidité.
Une très grande partie des utilisateurs de Dolphin exécutent des graphiques embarqués. Dans nos tests, les solutions embarquées au mieux ont pu atteindre une vitesse d'environ 50% avec les Ubershaders à 1x IR dans un jeu 3D typique! Les développeurs ont eu le sentiment d'ignorer un énorme groupe d'utilisateurs de Dolphin serait une erreur et de faire d'Ubershaders une victoire limitée au mieux. Les travaux se sont donc poursuivis pour trouver une solution encore plus robuste qui permettrait de guérir ces problèmes de performance une fois pour toutes.
Ubershaders en mode hybride
Hybrid Mode Ubershaders est un mariage d'Ubershaders et d'Asynchronous Shader Generation dans une solution magnifique qui prend les meilleures parties des deux avec aucun de leurs défauts. Comme le mode hybride réduit considérablement les coûts de performance des Ubershaders, nous pensons que c'est le mode Ubershader le plus utilisé.
En mode hybride, chaque fois qu'une nouvelle configuration de pipeline apparaît, Dolphin utilisera les Ubershaders déjà compilés pour rendre immédiatement l'effet sans bégayer tout en compilant le shader spécialisé en arrière-plan. Une fois le shader spécialisé terminé, Dolphin remettra alors les objets rendus à travers l'Ubershader à ces shaders spécialisés nouvellement générés.
En supposant que les pilotes et les API se comportent comme nous le voulons, c'est la solution parfaite. Comme les Ubershaders ne tournent que sur une fraction des objets d'une scène et que pour les images à la fois, le hit de performance est presque entièrement annulé et le bégaiement est complètement éliminé. Malheureusement, les pilotes et les API ne sont pas parfaits, ce qui limite l'efficacité de Hybrid dans certaines configurations. Cela nous amène à...
API d'Ubershaders et le Driver Hall of Shame
Les équipes de pilotes GPU ont un travail difficile qui leur permet de tirer le plus de puissance possible de leurs produits tout en offrant une expérience stable à leurs utilisateurs. Nous ne voulons pas manquer de respect à quiconque travaille sur ces pilotes, mais l'un des plus grands obstacles à ce projet a été un nombre ridicule de pilotes et d'API excentricités qui a forcé des solutions de contournement et d'autres changements dans les fonctionnalités.
En les mettant en lumière, nous espérons attirer l'attention sur eux. Peut-être quelqu'un en dehors du projet peut nous trouver une solution de contournement ou au moins le surveiller au cas où une future mise à jour pilote/API corrige le problème listé.
Génération de variantes de shader
Les conducteurs peuvent faire les choses d'une manière que nous n'attendons pas et que nous ne pouvons pas contrôler. Lorsque nous devons générer un nouveau pipeline pour un état de mélange ou de profondeur différent, certains conducteurs ne sont pas assez intelligents pour partager les ombres entre les pipelines. Cela provoquera un bégaiement mineur la première fois qu'un nouveau mode de mélange est utilisé. La plupart du temps, les variantes qu'un jeu utilisera sont générées dans les premières minutes de jeu, mais il peut encore être frustrant quand vous recherchez la perfection.
Heureusement, certains conducteurs sont assez intelligents pour partager les shaders entre les pipelines, comme le pilote Mesa, et il ne semble pas y avoir de bégaiement supplémentaire. Tous les autres pilotes disponibles semblent souffrir d'un bégaiement quelconque lors de la génération des variantes. Bien que nous ne pouvons rien y faire pour le moment, nous espérons qu'au fur et à mesure que les pilotes Vulkan mûriront, ils adopteront le comportement plus favorable de Mesa.
Verrouillage des shaders NVIDIA sur OpenGL et Vulkan
Certains utilisateurs ont rapporté que sur OpenGL et Vulkan (en particulier en mode hybride) il y a de très légers bégaiements lors de la compilation des shaders. Bien que nous ne soyons pas sûrs de ce qui ne va pas, car cela ne se produit pas en D3D, nous sommes assez sûrs que c'est un caprice dans le pilote de NVIDIA plutôt qu'une faute dans la façon dont Dolphin gère les choses. D'après nos tests, cela semble être distinct de la génération des variantes.
Les shaders compilés NVIDIA sur OpenGL et Vulkan sont beaucoup plus lents que le D3D
Celui-ci est particulièrement frustrant, car il n' y a pas de façon idéale de déboguer. Nous alimentons les mêmes shaders vers le GPU hôte sur OpenGL, Vulkan et D3D, mais D3D se retrouve avec des shaders beaucoup plus rapides que les deux autres. Cela signifie que sur une GTX 760, vous ne pouvez obtenir qu'une résolution interne de 1x dans un jeu particulier sur OpenGL ou Vulkan, mais sur D3D, être en mesure de doubler ou même tripler confortablement avant de voir le ralentissement.
Puisque NVIDIA ne nous permet pas de désassembler les shaders alors que tous les autres fournisseurs de GPU de bureau ont des shaders ouverts, nous n'avons aucun moyen de déboguer ceci ou de comprendre pourquoi le code compilé est tellement plus efficace sur D3D. Pensez à quel point c'est ridicule: nous voulons que Dolphin fonctionne mieux sur NVIDIA et ils ne fournissent pas les outils pour nous permettre d'essayer. C'est une décision déconcertante que nous espérons voir corrigée à l'avenir. Sans les outils de démontage des shaders fournis par d'autres fournisseurs, il aurait été beaucoup plus difficile de corriger divers bogues.
Le plus triste, c'est que les outils dont nous avons besoin existent - - si vous êtes un studio de jeu assez grand. Modifier: NVIDIA nous a informé qu'ils ne fournissent que des outils de désassemblage des shaders pour Direct3D 12 (sous NDA), et qu'ils ne sont pas disponibles pour les autres APIs indépendamment de NDA. Nous espérons que des outils pour d'autres API seront disponibles à l'avenir.
Le pilote Vulkan d'AMD manque toujours de support de cache Shader
Pendant la rédaction de cet article, nos souhaits ont été exaucés! Le pilote Vulkan d'AMD prend désormais en charge une mémoire cache shader! Cela améliore grandement ce qui était une situation désastreuse avec les Ubershaders, car cela signifiait que nous devions recompiler les Ubershaders à chaque manche. Il améliore également le bégaiement variante comme mentionné ci-dessus.
Les pilotes graphiques MacOS sont toujours terribles
Comme pour toute fonctionnalité excitante, les utilisateurs de macOS attendaient probablement l'inévitable "mais sur macOS..." et voilà. Les pilotes obsolètes et inefficaces d'OpenGL 4.1 sur Mac OS ne sont tout simplement pas à la hauteur de la tâche de manipuler les Ubershaders à n'importe quel degré utile. Le mode hybride réduira le bégaiement, mais Exclusive est trop lent pour être utile. Comme un autre mauvais côté macOS ne supporte toujours pas un cache de shader sous aucun pilote.
En conclusion
C'est étrange de parler du projet ubershader au passé au présent. Il est terminé, il est fusionné, et vous pouvez l'utiliser dès maintenant dans les dernières versions de développement. Bien qu'il puisse y avoir des problèmes de croissance ici et là, nous avons finalement notre solution pour le bégaiement de la compilation des shaders. Les Ubershaders vont s'améliorer au fil des ans car les cartes graphiques deviennent plus fortes et le mode Exclusive Mode peut être utilisé plus largement. Le mode hybride devrait également s'améliorer au fur et à mesure que les pilotes Vulkan mûrissent et que d'autres bizarreries des conducteurs sont, espérons-le, corrigées. Et, bien sûr, nous allons continuer à travailler de notre côté pour nous assurer que l'émulation continue de s'améliorer.
Bien que la compilation des shaders soit résolue efficacement, Dolphin a toujours besoin que l'ordinateur hôte soit assez rapide pour émuler le jeu. De plus, il y a des défauts dans l'équipe d'évaluation qui peuvent causer le bégaiement. Actuellement, Dolphin's JIT avec prise en charge des branches lutte vraiment sur les jeux qui utilisent un JIT (comme les jeux VC N64), provoquant un bégaiement qui ressemble à une compilation de shader mais n'est pas vraiment. Bien que nous espérions résoudre ce problème, nous inclurons probablement une option pour désactiver le support des branches si cela ne peut pas être corrigé, donc les utilisateurs ont le pouvoir de l'éteindre pour les titres problématiques.
À cause de cet article géant, nous n'allons pas faire de rapport d'étape ce mois-ci. Les nombreux changements étonnants de juillet se retrouveront dans le rapport d'étape du mois d'août. Ça va être un gros coup, alors n'hésitez pas à vous réjouir! D'ici là, profitez-en.
accueil | 
News | 
Blogs | 
Vidéos | 
Tests | 
Previews | 
Dossiers | 
Facebook
informations du groupe
tags : 
membres (30)
médias (1)
ajouter un commentaire | commentaires (4)
canal (1)
