Tweet
Salut !
Depuis longtemps , les développeurs de plugins utilisent OpenGL pour entre autres afficher des fenêtres dans X-Plane mais la mise en place de Vulkan, surtout depuis XP12 posent des problèmes de scintillement (flickering) et de baisse de performance importants.
JustSid est le développeur qui s'occupe presque exclusivement de ces problèmes .
JustSid à propos de ZINK (Blog Dev XP) :
X-Plane 12.04b3 est livré avec une nouvelle fonctionnalité appelée "Zink", qui, nous l'espérons, va atténuer un grand nombre de problèmes de longue date que de nombreux utilisateurs, en particulier avec les GPU AMD ont souffert (Pour le pilote AMD, Zink nécessite le pilote 23.2.1 au minimum, 23.2.2 fonctionne aussi. Tout ce qui est plus ancien ne supporte pas Zink malheureusement..
Nous espérons que cette fonctionnalité permettra de contourner les problèmes de scintillement des dessins des plugins, par exemple les écrans EFIS qui scintillent ou sont totalement absents, mais aussi d'améliorer les performances en réduisant la charge du pilote.
Si cela vous interesse, vous pouvez essayer dès maintenant en mettant à jour vers 12.04b3, en allant dans les paramètres graphiques et en cochant la case "Use Zink plugin bridge". Redémarrez X-Plane et si tout se passe comme prévu, X-Plane devrait avoir exactement l'apparence à laquelle vous êtes habitué, mais surtout vos plugins devraient avoir l'apparence correcte et vos performances pourraient être meilleures aussi. Parce que Zink est construit sur Vulkan, il n'est disponible que pour les utilisateurs de Windows et Linux et n'est pas applicable à macOS et Metal.
Si vous ne retenez qu'une seule chose de cet article, j'espère que cette image montrant la différence entre l'interopérabilité Vulkan/OpenGL native et l'interopérabilité Zink vous donnera une idée des raisons de notre enthousiasme :
note : en haut à gauche des 2 mages , regardez les différences de fps f.act entre Native et Zink
Maintenant que j'ai, je l'espère, votre attention, laissez-moi vous expliquer comment nous en sommes arrivés là et ce que cela signifie pour les utilisateurs et les développeurs. Tout d'abord, Zink est en fait un pilote graphique qui se situe entre les plugins et X-Plane et traduit le rendu OpenGL des plugins en commandes Vulkan natives qui sont exécutées par le même périphérique Vulkan que X-Plane utilise pour le rendu. Bien sûr, X-Plane lui-même n'utilise plus OpenGL, mais c'est toujours très important pour le développement de plugins. Il y a longtemps, lorsque X-Plane était encore basé sur OpenGL et que le SDK pour les plugins a été créé, il semblait évident d'exposer directement le contexte OpenGL de X-Plane aux plugins et de les laisser gérer eux-mêmes tous leurs besoins en matière de dessin. Cela donne le plus de flexibilité et de contrôle sur tout, et cela facilite également le SDK car il n'y a pas besoin de créer des routines de dessin fantaisistes à utiliser par les plugins.
Avance rapide jusqu'au portage de Vulkan et Metal et nous avons soudainement un problème : Ni Vulkan ni Metal ne sont OpenGL, mais il existe maintenant des centaines de plugins qui supposent tous que X-Plane utilise OpenGL et que le contexte OpenGL est présent. Tuer OpenGL pour les plugins signifierait que d'innombrables plugins cesseraient de fonctionner, nécessitant des processus de mise à jour potentiellement longs ou peut-être qu'ils ne fonctionneraient plus du tout parce que l'auteur a perdu tout intérêt pour X-Plane ou le développement du plugin. C'est ainsi que nous nous sommes retrouvés avec l'OpenGL Bridge dans X-Plane 11.50 : Nous créons un véritable contexte OpenGL, partageons de la mémoire depuis Vulkan vers ce contexte OpenGL, puis laissons les plugins continuer à dessiner comme ils le faisaient auparavant. X-Plane se charge de toutes les règles de synchronisation et de création de ressources sous le capot et tout le monde est content. Tout le monde ? Eh bien, non, pas tout à fait...
Le problème de l'interopérabilité Vulkan/OpenGL
Le gros problème de l'interopérabilité Vulkan/OpenGL est qu'elle dépend du pilote qui la prend en charge correctement. Si vous possédez une carte AMD, vous pouvez probablement raconter de longues histoires sur les problèmes rencontrés. Le plus important est le scintillement ou l'absence totale de rendu. Dans ce cas, le dessin des plugins est soit complètement absent, soit vacillant, ce qui rend l'utilisation des plugins pratiquement impossible. L'autre problème est la performance, capturée dans la capture d'écran ci-dessus, où le pont OpenGL ajoute presque 10ms par image, bien que j'ai vu des chiffres aussi mauvais que 30ms par image. Pour référence, 33ms est le temps qu'une image peut prendre au maximum pour atteindre 30 FPS ! Ce n'était pas toujours le cas, cela fonctionnait bien mieux avant, mais les régressions de pilotes sont une chose réelle et ce n'est pas vraiment quelque chose que les vendeurs de matériel testent. Je ne peux pas être trop en colère à ce sujet, X-Plane est l'une des rares applications qui utilise cette fonctionnalité. Bien que nous ayons déposé de nombreux rapports de bogues auprès des fournisseurs, les problèmes n'ont malheureusement jamais été complètement résolus, donc même pendant les jours de la 11.50, nous avons commencé à réfléchir à des alternatives. Pendant les jours de X-Plane 11, il était au moins assez facile de dire aux utilisateurs de revenir à OpenGL pour éviter le scintillement, même si cela signifiait généralement une perte de performance parce que le backend Vulkan était tellement plus rapide.
Il existe bien sûr d'autres pilotes OpenGL open source qui ne sont pas Zink. Le plus connu est probablement Angle, une implémentation d'OpenGL ES par Google. Aucun d'entre eux ne fonctionne pour nous cependant, à cause d'une autre décision terrible prise il y a plusieurs années : X-Plane a toujours utilisé un contexte OpenGL de profil de compatibilité. Ce que cela signifie n'a pas d'importance, mais le résultat final est que X-Plane et par extension les plugins, dépendent de l'existence de commandes OpenGL des années 90 ! La plupart des implémentations modernes d'OpenGL ignorent volontiers tout du profil de compatibilité parce que c'est un cauchemar à implémenter et que cela ne correspond pas du tout au matériel moderne. Mais beaucoup de plugins utilisent ces anciennes fonctionnalités et s'appuient sur le pipeline de fonctions fixes. C'est d'ailleurs la raison pour laquelle nous n'avons pas simplement exposé Vulkan ou Metal aux développeurs. L'écriture d'un moteur de rendu Vulkan ou Metal nécessite une tonne de frais généraux, est profondément compliquée et sujette aux erreurs. L'écriture d'un code correct nécessite des tests sur différents matériels, la lecture de quelques milliers de pages de texte de spécification et une bonne compréhension du matériel sous-jacent. La plupart des développeurs de plugins ne s'aventurent pas au-delà du pipeline de fonctions fixes, il serait absolument déraisonnable d'attendre d'eux qu'ils consacrent le temps et les efforts nécessaires à cette tâche.
C'est quoi un Zink ?
Heureusement, nous n'avons pas besoin de jeter les développeurs dans le grand bain, car il existe Zink. Zink fait partie du projet open source Mesa et est un backend pour le pilote Gallium, qui est le frontend OpenGL fourni par Mesa. Ok, beaucoup de grands mots ici, simplifions un peu les choses : Gallium implémente OpenGL 1.0 à OpenGL 4.6, ce qui signifie en gros "tout OpenGL". Mais il n'en fait rien, il se contente de faire tout le travail nécessaire pour faire fonctionner OpenGL. Les backends sont ceux qui transforment les données intermédiaires produites par Gallium en commandes réelles à exécuter par un GPU. Il existe un grand nombre de ces backends : Par exemple, il existe de nombreux logiciels de rendu qui n'utilisent que le CPU, des implémentations qui parlent aux GPU AMD, aux GPU Nvidia, aux GPU Intel, des choses dont je n'ai jamais entendu parler, tout est là. Mais parmi tous ces backends, il y a aussi Zink. Zink prend simplement ce que Gallium produit et en fait des commandes Vulkan qui peuvent être exécutées par n'importe quel matériel compatible avec Vulkan. C'est ce qui rend Zink si génial pour nous, c'est une véritable implémentation d'OpenGL qui inclut tous les bits difficiles et compliqués dont nous avons besoin pour faire fonctionner les plugins.
Bien sûr, j'ai donné l'impression que c'était plus facile que ça ne l'est en réalité, "juste" écrire un backend Gallium qui parle Vulkan comme par magie représente beaucoup de travail. Le héros méconnu de tout cela est Mike Blumenkrantz, le grand patron et développeur principal de Zink. Il a passé des années à faire de Zink ce qu'il est aujourd'hui et travaille sans relâche à son amélioration, tant en termes de fonctionnalités que de performances. C'est aussi une légende absolue et rien de tout ce qui concerne l'interopérabilité de Zink avec X-Plane n'existerait sans son aide, non seulement pour amener Zink là où il est, mais aussi pour répondre à des tonnes de nos questions pendant l'intégration. Un grand bravo à Mike ! Puisque je fais des remerciements, il serait injuste de ma part de ne pas mentionner AMD. Bien qu'ils soient en partie la raison pour laquelle nous sommes ici aujourd'hui, ils nous ont également fourni de l'aide et des mises à jour de pilotes pour que Zink fonctionne avec X-Plane et tous les ingénieurs que j'ai rencontrés au cours de ce voyage ont été tout à fait aimables et utiles.
Je suis un utilisateur, en quoi cela me concerne-t-il ?
Si vous êtes sur X-Plane 12.04b3, ouvrez vos paramètres graphiques et activez le backend Zink. Par défaut, nous utilisons le backend OpenGL natif pour des raisons de compatibilité, bien que l'objectif à long terme soit de passer exclusivement à Zink, mais pas de sitôt. Il est possible que certains ou tous vos plugins explosent, nous avons fait des tests avec des développeurs tiers à ce sujet, mais la zone touchée par ce problème est immense et nous ne pouvons pas tester tous les plugins existants. S'il est cassé, ne vous inquiétez pas, remplissez un rapport de bogue et faites-le nous savoir, revenez au backend OpenGL natif et réessayez à l'avenir. L'idée derrière Zink est de faire en sorte qu'il fonctionne le plus possible, mais c'est la première étape et si ce n'est pas parfait dès le départ, j'espère que vous aurez un peu de patience avec nous. Je dis cela parce que, comme je l'ai dit, la surface touchée est immense ici et l'envoi d'un pilote graphique complet avec une application n'est pas vraiment quelque chose de très courant et, comme je l'ai constaté, cela casse parfois des choses.
La bonne nouvelle est que Zink est open source et que nous le construisons nous-mêmes, ce qui signifie que, pour la première fois, nous pouvons voir sous le capot quand les choses explosent. J'ai bon espoir que cela nous aidera à trouver les problèmes beaucoup plus rapidement que d'habitude. Normalement, les pilotes sont livrés avec toutes les données de débogage dépouillées. J'ai donc vu plusieurs fois des bogues qui s'arrêtent quelque part dans le pilote sans qu'il soit possible de savoir ce qui s'est passé ou comment le reproduire. Parfois, nous n'avons même pas d'informations du tout parce que le problème a été complètement embrouillé.
Je suis un développeur, en quoi cela me concerne-t-il ?
Eh bien, la même chose que ci-dessus : Testez vos plugins, signalez les bogues, soyez patient. Mais aussi, il y a quelques choses dont vous devriez être conscient en général :
Premièrement, X-Plane vous permet enfin d'activer un contexte de débogage GL. Si vous exécutez X-Plane avec --debug_gl, X-Plane créera un contexte de débogage GL pour vous et mettra en place les callbacks nécessaires. Par défaut, il imprimera tous les messages dans stdout et les erreurs obtiendront un grand pop up en sim. Mais vous pouvez toujours le rediriger vers quelque chose de votre choix en appelant glDebugMessageCallbackARB() avec votre propre callback. S'il vous plaît, ne publiez pas de plugins avec un gestionnaire activé, car cela pourrait conduire les autres développeurs à ne pas être en mesure de définir leur propre callback car il ne peut y en avoir qu'un seul. Le contexte de débogage GL est disponible lors de l'exécution par Zink et également par le pilote GL natif.
Il y en a deux, à ma connaissance :
En théorie, vous pouvez créer un contexte GL partagé pour le traitement GL en arrière-plan, mais ce n'est pas toujours stable à 100%. J'essaie toujours de trouver un problème quelque part dans la pile qui conduit à la suppression incorrecte des ressources, donc si vous rencontrez des problèmes avec un contexte GL partagé, cela pourrait être le cas. Essayez-le quand même !
Ne désactivez pas et/ou n'activez pas GL_FRAMEBUFFER_SRGB, cela entraînera la disparition de tous les rendus ultérieurs. Ce bogue, je l'ai traqué plus loin dans Mesa et le problème est que le pilote va créer une copie de l'image pour ajouter ou supprimer le bit sRGB, mais il ne finit jamais par recopier le résultat. En théorie, cela devrait être géré par une simple vue sur la même image sans aucune copie, mais de toute façon, c'est actuellement cassé.
Si vous voulez tester Zink dans le cadre d'une solution CI, vous pouvez aussi lancer X-Plane avec --zink ou --no_zink par la ligne de commande et cela remplacera ce qui a été défini dans les paramètres graphiques.
Je suis sous macOS et je me sens exclu.
Tout d'abord, je suis désolé d'entendre cela. La version 12.04 offre également de grandes choses aux utilisateurs de macOS, que vous allez adorer, j'en suis sûr.
Dans le long terme, nous avons l'idée de faire tourner Zink sur macOS également, mais cette fois-ci au-dessus de Metal. GL sur macOS est déjà émulé par Metal, mais Apple le fait sans visibilité ni moyen de l'exploiter. Nous rêvons un peu de faire fonctionner des plugins au-dessus de Zink au-dessus de MoltenVK au-dessus de Metal, mais c'est purement une idée pour le moment et aucun code n'a été écrit pour cela. Cette approche présenterait toutefois deux avantages : Premièrement, Apple a déjà déprécié OpenGL dans macOS et bien que je pense qu'ils continueront à le supporter, de peur que leurs utilisateurs professionnels ne grimpent sur leur toit et crient au meurtre, ils n'ont clairement aucun intérêt à étendre davantage le support d'OpenGL. Deuxièmement, si nous arrivons à réduire la passerelle OpenGL à Zink sur toutes les plateformes, ce sera une aubaine pour les développeurs car ils pourront cibler une seule implémentation OpenGL et couvrir toutes les plateformes en une seule fois. Cela permettrait également d'apporter enfin le support d'OpenGL 4.6 à macOS, qui est actuellement limité à OpenGL 2.1.
Depuis longtemps , les développeurs de plugins utilisent OpenGL pour entre autres afficher des fenêtres dans X-Plane mais la mise en place de Vulkan, surtout depuis XP12 posent des problèmes de scintillement (flickering) et de baisse de performance importants.
JustSid est le développeur qui s'occupe presque exclusivement de ces problèmes .
JustSid à propos de ZINK (Blog Dev XP) :
X-Plane 12.04b3 est livré avec une nouvelle fonctionnalité appelée "Zink", qui, nous l'espérons, va atténuer un grand nombre de problèmes de longue date que de nombreux utilisateurs, en particulier avec les GPU AMD ont souffert (Pour le pilote AMD, Zink nécessite le pilote 23.2.1 au minimum, 23.2.2 fonctionne aussi. Tout ce qui est plus ancien ne supporte pas Zink malheureusement..
Nous espérons que cette fonctionnalité permettra de contourner les problèmes de scintillement des dessins des plugins, par exemple les écrans EFIS qui scintillent ou sont totalement absents, mais aussi d'améliorer les performances en réduisant la charge du pilote.
Si cela vous interesse, vous pouvez essayer dès maintenant en mettant à jour vers 12.04b3, en allant dans les paramètres graphiques et en cochant la case "Use Zink plugin bridge". Redémarrez X-Plane et si tout se passe comme prévu, X-Plane devrait avoir exactement l'apparence à laquelle vous êtes habitué, mais surtout vos plugins devraient avoir l'apparence correcte et vos performances pourraient être meilleures aussi. Parce que Zink est construit sur Vulkan, il n'est disponible que pour les utilisateurs de Windows et Linux et n'est pas applicable à macOS et Metal.
Si vous ne retenez qu'une seule chose de cet article, j'espère que cette image montrant la différence entre l'interopérabilité Vulkan/OpenGL native et l'interopérabilité Zink vous donnera une idée des raisons de notre enthousiasme :
note : en haut à gauche des 2 mages , regardez les différences de fps f.act entre Native et Zink
Maintenant que j'ai, je l'espère, votre attention, laissez-moi vous expliquer comment nous en sommes arrivés là et ce que cela signifie pour les utilisateurs et les développeurs. Tout d'abord, Zink est en fait un pilote graphique qui se situe entre les plugins et X-Plane et traduit le rendu OpenGL des plugins en commandes Vulkan natives qui sont exécutées par le même périphérique Vulkan que X-Plane utilise pour le rendu. Bien sûr, X-Plane lui-même n'utilise plus OpenGL, mais c'est toujours très important pour le développement de plugins. Il y a longtemps, lorsque X-Plane était encore basé sur OpenGL et que le SDK pour les plugins a été créé, il semblait évident d'exposer directement le contexte OpenGL de X-Plane aux plugins et de les laisser gérer eux-mêmes tous leurs besoins en matière de dessin. Cela donne le plus de flexibilité et de contrôle sur tout, et cela facilite également le SDK car il n'y a pas besoin de créer des routines de dessin fantaisistes à utiliser par les plugins.
Avance rapide jusqu'au portage de Vulkan et Metal et nous avons soudainement un problème : Ni Vulkan ni Metal ne sont OpenGL, mais il existe maintenant des centaines de plugins qui supposent tous que X-Plane utilise OpenGL et que le contexte OpenGL est présent. Tuer OpenGL pour les plugins signifierait que d'innombrables plugins cesseraient de fonctionner, nécessitant des processus de mise à jour potentiellement longs ou peut-être qu'ils ne fonctionneraient plus du tout parce que l'auteur a perdu tout intérêt pour X-Plane ou le développement du plugin. C'est ainsi que nous nous sommes retrouvés avec l'OpenGL Bridge dans X-Plane 11.50 : Nous créons un véritable contexte OpenGL, partageons de la mémoire depuis Vulkan vers ce contexte OpenGL, puis laissons les plugins continuer à dessiner comme ils le faisaient auparavant. X-Plane se charge de toutes les règles de synchronisation et de création de ressources sous le capot et tout le monde est content. Tout le monde ? Eh bien, non, pas tout à fait...
Le problème de l'interopérabilité Vulkan/OpenGL
Le gros problème de l'interopérabilité Vulkan/OpenGL est qu'elle dépend du pilote qui la prend en charge correctement. Si vous possédez une carte AMD, vous pouvez probablement raconter de longues histoires sur les problèmes rencontrés. Le plus important est le scintillement ou l'absence totale de rendu. Dans ce cas, le dessin des plugins est soit complètement absent, soit vacillant, ce qui rend l'utilisation des plugins pratiquement impossible. L'autre problème est la performance, capturée dans la capture d'écran ci-dessus, où le pont OpenGL ajoute presque 10ms par image, bien que j'ai vu des chiffres aussi mauvais que 30ms par image. Pour référence, 33ms est le temps qu'une image peut prendre au maximum pour atteindre 30 FPS ! Ce n'était pas toujours le cas, cela fonctionnait bien mieux avant, mais les régressions de pilotes sont une chose réelle et ce n'est pas vraiment quelque chose que les vendeurs de matériel testent. Je ne peux pas être trop en colère à ce sujet, X-Plane est l'une des rares applications qui utilise cette fonctionnalité. Bien que nous ayons déposé de nombreux rapports de bogues auprès des fournisseurs, les problèmes n'ont malheureusement jamais été complètement résolus, donc même pendant les jours de la 11.50, nous avons commencé à réfléchir à des alternatives. Pendant les jours de X-Plane 11, il était au moins assez facile de dire aux utilisateurs de revenir à OpenGL pour éviter le scintillement, même si cela signifiait généralement une perte de performance parce que le backend Vulkan était tellement plus rapide.
Il existe bien sûr d'autres pilotes OpenGL open source qui ne sont pas Zink. Le plus connu est probablement Angle, une implémentation d'OpenGL ES par Google. Aucun d'entre eux ne fonctionne pour nous cependant, à cause d'une autre décision terrible prise il y a plusieurs années : X-Plane a toujours utilisé un contexte OpenGL de profil de compatibilité. Ce que cela signifie n'a pas d'importance, mais le résultat final est que X-Plane et par extension les plugins, dépendent de l'existence de commandes OpenGL des années 90 ! La plupart des implémentations modernes d'OpenGL ignorent volontiers tout du profil de compatibilité parce que c'est un cauchemar à implémenter et que cela ne correspond pas du tout au matériel moderne. Mais beaucoup de plugins utilisent ces anciennes fonctionnalités et s'appuient sur le pipeline de fonctions fixes. C'est d'ailleurs la raison pour laquelle nous n'avons pas simplement exposé Vulkan ou Metal aux développeurs. L'écriture d'un moteur de rendu Vulkan ou Metal nécessite une tonne de frais généraux, est profondément compliquée et sujette aux erreurs. L'écriture d'un code correct nécessite des tests sur différents matériels, la lecture de quelques milliers de pages de texte de spécification et une bonne compréhension du matériel sous-jacent. La plupart des développeurs de plugins ne s'aventurent pas au-delà du pipeline de fonctions fixes, il serait absolument déraisonnable d'attendre d'eux qu'ils consacrent le temps et les efforts nécessaires à cette tâche.
C'est quoi un Zink ?
Heureusement, nous n'avons pas besoin de jeter les développeurs dans le grand bain, car il existe Zink. Zink fait partie du projet open source Mesa et est un backend pour le pilote Gallium, qui est le frontend OpenGL fourni par Mesa. Ok, beaucoup de grands mots ici, simplifions un peu les choses : Gallium implémente OpenGL 1.0 à OpenGL 4.6, ce qui signifie en gros "tout OpenGL". Mais il n'en fait rien, il se contente de faire tout le travail nécessaire pour faire fonctionner OpenGL. Les backends sont ceux qui transforment les données intermédiaires produites par Gallium en commandes réelles à exécuter par un GPU. Il existe un grand nombre de ces backends : Par exemple, il existe de nombreux logiciels de rendu qui n'utilisent que le CPU, des implémentations qui parlent aux GPU AMD, aux GPU Nvidia, aux GPU Intel, des choses dont je n'ai jamais entendu parler, tout est là. Mais parmi tous ces backends, il y a aussi Zink. Zink prend simplement ce que Gallium produit et en fait des commandes Vulkan qui peuvent être exécutées par n'importe quel matériel compatible avec Vulkan. C'est ce qui rend Zink si génial pour nous, c'est une véritable implémentation d'OpenGL qui inclut tous les bits difficiles et compliqués dont nous avons besoin pour faire fonctionner les plugins.
Bien sûr, j'ai donné l'impression que c'était plus facile que ça ne l'est en réalité, "juste" écrire un backend Gallium qui parle Vulkan comme par magie représente beaucoup de travail. Le héros méconnu de tout cela est Mike Blumenkrantz, le grand patron et développeur principal de Zink. Il a passé des années à faire de Zink ce qu'il est aujourd'hui et travaille sans relâche à son amélioration, tant en termes de fonctionnalités que de performances. C'est aussi une légende absolue et rien de tout ce qui concerne l'interopérabilité de Zink avec X-Plane n'existerait sans son aide, non seulement pour amener Zink là où il est, mais aussi pour répondre à des tonnes de nos questions pendant l'intégration. Un grand bravo à Mike ! Puisque je fais des remerciements, il serait injuste de ma part de ne pas mentionner AMD. Bien qu'ils soient en partie la raison pour laquelle nous sommes ici aujourd'hui, ils nous ont également fourni de l'aide et des mises à jour de pilotes pour que Zink fonctionne avec X-Plane et tous les ingénieurs que j'ai rencontrés au cours de ce voyage ont été tout à fait aimables et utiles.
Je suis un utilisateur, en quoi cela me concerne-t-il ?
Si vous êtes sur X-Plane 12.04b3, ouvrez vos paramètres graphiques et activez le backend Zink. Par défaut, nous utilisons le backend OpenGL natif pour des raisons de compatibilité, bien que l'objectif à long terme soit de passer exclusivement à Zink, mais pas de sitôt. Il est possible que certains ou tous vos plugins explosent, nous avons fait des tests avec des développeurs tiers à ce sujet, mais la zone touchée par ce problème est immense et nous ne pouvons pas tester tous les plugins existants. S'il est cassé, ne vous inquiétez pas, remplissez un rapport de bogue et faites-le nous savoir, revenez au backend OpenGL natif et réessayez à l'avenir. L'idée derrière Zink est de faire en sorte qu'il fonctionne le plus possible, mais c'est la première étape et si ce n'est pas parfait dès le départ, j'espère que vous aurez un peu de patience avec nous. Je dis cela parce que, comme je l'ai dit, la surface touchée est immense ici et l'envoi d'un pilote graphique complet avec une application n'est pas vraiment quelque chose de très courant et, comme je l'ai constaté, cela casse parfois des choses.
La bonne nouvelle est que Zink est open source et que nous le construisons nous-mêmes, ce qui signifie que, pour la première fois, nous pouvons voir sous le capot quand les choses explosent. J'ai bon espoir que cela nous aidera à trouver les problèmes beaucoup plus rapidement que d'habitude. Normalement, les pilotes sont livrés avec toutes les données de débogage dépouillées. J'ai donc vu plusieurs fois des bogues qui s'arrêtent quelque part dans le pilote sans qu'il soit possible de savoir ce qui s'est passé ou comment le reproduire. Parfois, nous n'avons même pas d'informations du tout parce que le problème a été complètement embrouillé.
Je suis un développeur, en quoi cela me concerne-t-il ?
Eh bien, la même chose que ci-dessus : Testez vos plugins, signalez les bogues, soyez patient. Mais aussi, il y a quelques choses dont vous devriez être conscient en général :
Premièrement, X-Plane vous permet enfin d'activer un contexte de débogage GL. Si vous exécutez X-Plane avec --debug_gl, X-Plane créera un contexte de débogage GL pour vous et mettra en place les callbacks nécessaires. Par défaut, il imprimera tous les messages dans stdout et les erreurs obtiendront un grand pop up en sim. Mais vous pouvez toujours le rediriger vers quelque chose de votre choix en appelant glDebugMessageCallbackARB() avec votre propre callback. S'il vous plaît, ne publiez pas de plugins avec un gestionnaire activé, car cela pourrait conduire les autres développeurs à ne pas être en mesure de définir leur propre callback car il ne peut y en avoir qu'un seul. Le contexte de débogage GL est disponible lors de l'exécution par Zink et également par le pilote GL natif.
Il y en a deux, à ma connaissance :
En théorie, vous pouvez créer un contexte GL partagé pour le traitement GL en arrière-plan, mais ce n'est pas toujours stable à 100%. J'essaie toujours de trouver un problème quelque part dans la pile qui conduit à la suppression incorrecte des ressources, donc si vous rencontrez des problèmes avec un contexte GL partagé, cela pourrait être le cas. Essayez-le quand même !
Ne désactivez pas et/ou n'activez pas GL_FRAMEBUFFER_SRGB, cela entraînera la disparition de tous les rendus ultérieurs. Ce bogue, je l'ai traqué plus loin dans Mesa et le problème est que le pilote va créer une copie de l'image pour ajouter ou supprimer le bit sRGB, mais il ne finit jamais par recopier le résultat. En théorie, cela devrait être géré par une simple vue sur la même image sans aucune copie, mais de toute façon, c'est actuellement cassé.
Si vous voulez tester Zink dans le cadre d'une solution CI, vous pouvez aussi lancer X-Plane avec --zink ou --no_zink par la ligne de commande et cela remplacera ce qui a été défini dans les paramètres graphiques.
Je suis sous macOS et je me sens exclu.
Tout d'abord, je suis désolé d'entendre cela. La version 12.04 offre également de grandes choses aux utilisateurs de macOS, que vous allez adorer, j'en suis sûr.
Dans le long terme, nous avons l'idée de faire tourner Zink sur macOS également, mais cette fois-ci au-dessus de Metal. GL sur macOS est déjà émulé par Metal, mais Apple le fait sans visibilité ni moyen de l'exploiter. Nous rêvons un peu de faire fonctionner des plugins au-dessus de Zink au-dessus de MoltenVK au-dessus de Metal, mais c'est purement une idée pour le moment et aucun code n'a été écrit pour cela. Cette approche présenterait toutefois deux avantages : Premièrement, Apple a déjà déprécié OpenGL dans macOS et bien que je pense qu'ils continueront à le supporter, de peur que leurs utilisateurs professionnels ne grimpent sur leur toit et crient au meurtre, ils n'ont clairement aucun intérêt à étendre davantage le support d'OpenGL. Deuxièmement, si nous arrivons à réduire la passerelle OpenGL à Zink sur toutes les plateformes, ce sera une aubaine pour les développeurs car ils pourront cibler une seule implémentation OpenGL et couvrir toutes les plateformes en une seule fois. Cela permettrait également d'apporter enfin le support d'OpenGL 4.6 à macOS, qui est actuellement limité à OpenGL 2.1.
Commentaire