Kivy: Problème Raspberry Pi OpenGL avec screenmanager

J'ai effectué d'autres tests pour essayer d'isoler ce problème en utilisant des images plus petites et une simple application de test de diaporama. Dans tous les cas, screenmanager semble être à l'origine des erreurs OpenGL glGetError 0x502 et 0x505. De plus, en utilisant free -h -s 1 j'ai analysé l'utilisation de la mémoire et j'ai trouvé qu'il n'y avait pas de problème de mémoire GPU ainsi que l'exécution de l'application glxgears pour montrer qu'OpenGL est installé et opérationnel.

Pour fournir ces cas de test, j'ai téléchargé une copie du simple screenmanagertest.py et des exemples d'images dans le lien ci-dessous dans un dossier contenant des fichiers de test pour reproduire les symptômes de ce problème.

https://goo.gl/6e7edY

Vous trouverez ci-dessous l'utilisation de la mémoire lors de l'exécution de ces tests :
total utilisé buff/cache partagé gratuit disponible
Mémoire : 479M 223M 53M 11M 203M 194M
Échange : 99M 32M 67M

Quelqu'un soutient-il encore Kivy ? Je n'ai reçu aucune réponse ici depuis plus d'une semaine. Dois-je juste abandonner ?

Je n'ai reçu aucune réponse ici depuis plus d'une semaine. Dois-je juste abandonner ?

Malheureusement, personne n'est payé pour résoudre les problèmes ou répondre aux rapports de bogues ici. Il y a plus de bogues que de ressources disponibles pour les corriger, et l'arriéré de problèmes s'étend sur plusieurs années. N'abandonnez certainement pas, mais considérez que vous ne payez pas pour le développement ou la maintenance des produits. Il incombe aux utilisateurs individuels (comme vous et moi) de participer au développement, aux discussions, de contribuer au code, etc.

Je n'ai pas de réponse pour vous, car je n'ai jamais utilisé Kivy avec RPi. Mais il semble que vous utilisiez SDL2 et que vous exécutiez sous X, n'est-ce pas ? Pour autant que je sache, cela même étant possible est un développement relativement récent du côté RPi. Avez-vous essayé le pilote BCM sans X ? Je ne sais pas avec certitude si cela fonctionne sur RPi3, mais cela semble valoir le coup - si rien d'autre, cela pourrait isoler davantage le problème de "SDL2 sur RPi3".

Merci bionoid pour vos commentaires. Je comprends que les ressources sont rares puisque j'ai passé plus d'un an à développer un prototype sur Android qui a échoué, c'est pourquoi je migre vers RPi3. J'espérais qu'il pourrait y avoir plus de développeurs pour que Linux puisse m'aider, mais apparemment non.

En ce qui concerne les pilotes SDL2, X et BCM, cela dépasse ma compréhension quant à la manière dont ils sont installés ou utilisés. Je suis également intéressé à apprendre des solutions alternatives pour participer au développement, aux discussions, contribuer au code, etc. Toutes les suggestions sont appréciées.

Tout d'abord... Cela se produit-il avec moins d'images ? Comme deux ? Si cela ne produit pas d'erreur, vous manquez probablement de mémoire.

En ce qui concerne les pilotes SDL2, X et BCM, cela dépasse ma compréhension

Kivy est livré avec un fournisseur de fenêtres spécifiquement pour le GPU Raspberry, lien source (cela remonte à RPi2). Je l'ai appelé bcm, ce n'est peut-être pas techniquement correct, broadcom fabrique le SoC, "videocore" est peut-être mieux... de toute façon, X-windows est l'interface utilisateur graphique sous Linux. Citant votre journal ci-dessus :

SDL2 trouvé via pkg-config
Fichiers de bibliothèque brcmEGL et brcmGLES trouvés pour la plate-forme rpi dans /opt/vc/lib/

Il détecte SDL2 et le GPU Raspberry, mais vous n'affichez pas la partie du journal qui indique quel fournisseur de fenêtres est réellement utilisé. Je suppose que vous l'utilisez depuis l'interface utilisateur graphique de X ?
Si c'est le cas, ma meilleure suggestion pour recueillir plus d'informations est d' activer le mode console et de voir si vous pouvez faire fonctionner Kivy avec le pilote videocore, et s'il y a une différence.

Merci encore bionoid pour votre aide. J'ai été occupé à construire et à tester pour en savoir plus sur ces différents packages, c'est pourquoi je réponds tardivement. J'ai également reçu des conseils de pmpp sur le forum kivy concernant l'utilisation de gl4es que j'ai également testé. J'ai également créé une image de démarrage de la version Kivy-Pie mais j'obtiens les mêmes résultats lors du test de screenmanager (application simple comme la mienne qui présente des symptômes similaires). Mes tests utilisent deux images jpg et j'ai joint le code, le journal de la console et les images utilisées dans le diaporama (qui doivent se trouver dans le dossier /home/pi/.masterpics/pix).

La version Kivy-Pie utilise uniquement le gestionnaire de fenêtres FluxBox, donc je pense que Kivy fonctionne sous X sur cette version mais génère toujours les erreurs 'glGetError 0x0502' et 'FBO Initialization failed: Incomplete attachment' que vous voyez dans ce journal. Je vois également l'erreur de mémoire insuffisante 'glGetError 0x0505' immédiatement après l'échec de l'initialisation FBO.

Quant à gl4es , je l'ai installé sur la version NOOB mais je n'ai vu aucune différence dans les journaux (NOOBS et Kivy-Pie). Donc, je ne sais pas quoi faire ensuite avec ça. J'ai demandé de l'aide sur le forum kivy à ce sujet mais je n'ai pas obtenu de réponse. Je peux réessayer.

Donc, j'ai pensé partager où je suis et demander si vous pouviez m'aider à mieux comprendre comment les conducteurs sont faits pour fonctionner. Vous avez mentionné le pilote videocore mais je ne sais pas s'il est déjà installé ou non et comment l'installer sinon. J'ai trouvé videocoreiv mais je ne sais pas quoi en faire. Désolé, je devrai peut-être prendre le temps d'étudier davantage l'histoire de Raspberry pour comprendre tout cela. Toutes les suggestions de vous ou de quiconque sont grandement appréciées.

screenmanagertest.py.txt
16GB-KP-screenmanagertest-log.txt

Malheureusement, je ne connais rien à OpenGL ou à Raspberry, donc je n'ai pas beaucoup de suggestions au-delà de ce que j'ai dit dans le commentaire précédent.

Le pilote videocore est ce que Kivy utilise si vous ne l'exécutez pas sous X, ce que je vous ai proposé d'essayer à titre de comparaison. Sur RPi2, il n'était pas possible de fonctionner sous X pour autant que je sache, donc la configuration que vous utilisez n'a peut-être pas été testée aussi largement

Et pour être clair, pour autant que je sache, vous n'avez pas besoin d'installer ou de faire quoi que ce soit de spécial pour utiliser le videocore, à moins de le compiler avec succès et de ne pas l'exécuter sous X. Tant que cela est présent lorsque vous construisez, Je pense que tu es prêt :

Found brcmEGL and brcmGLES library filesfor rpi platform at /opt/vc/lib/

Il semble que tous les "pilotes" GL sont installés, même videocore, selon la ligne ci-dessous du journal :

"Rendu OpenGL <"VideoCore IV HW">"

Dois-je demander à quelqu'un de l'organisation de développement kivy s'il/elle a des suggestions à me faire rechercher et corriger ? C'est ma dernière tentative d'utiliser Kivy pour mon produit. J'avais espéré que Linux réussirait.

“OpenGL renderer <“VideoCore IV HW”>“

Eh bien, c'est le nom du matériel ; ce que vous devez vérifier est le fournisseur de fenêtres signalé, je pense que cela devrait être egl_rpi si vous le faites correctement (ce ne devrait pas être sdl2). Donc, sous fluxbox, vous n'utilisez pas le pilote inclus de Kivy. Vous devriez au moins l'essayer, si rien d'autre ne confirme qu'il a le même problème. Comme je l'ai dit au début, OpenGL dans X sur RPi3 est un développement récent, donc ce que vous rencontrez n'est peut-être même pas un problème de Kivy.

Dois-je demander à quelqu'un de l'organisation de développement kivy s'il/elle a des suggestions à me faire rechercher et corriger ? [...]

Les mainteneurs de Kivy lisent ici sur le suivi des problèmes, mais n'utilisent probablement pas RPi3 (ou même en possèdent un pour essayer de le reproduire). Vous pouvez essayer de poster sur la liste de diffusion kivy-users, ou demander sur freenode, peut-être que quelqu'un a des idées.

Merci encore pour votre aide. Pouvez-vous m'indiquer la direction à suivre pour faire ce que vous suggérez ci-dessous ? Je ne sais pas comment configurer fluxbox ou quel pilote Kivy utiliser. Le fournisseur de fenêtre est egl_rpi et le fournisseur de texte est sdl2.

“Ainsi, sous fluxbox, vous n'utilisez pas le pilote inclus de Kivy. Vous devriez au moins l'essayer, si rien d'autre ne confirme qu'il a le même problème.

Je poste également sur le forum OpenGL et j'espère que ce que vous avez fourni m'aidera de leur côté. Merci encore!

Honnêtement, je n'en ai aucune idée, ma meilleure estimation est le lien que je vous ai donné dans le premier commentaire - activer le mode console . À partir de là, il devrait simplement compiler et exécuter kivy pour autant que je sache

Merci encore bionoid. J'ai construit une image de Kivy-Pie et utilisé mon code dépouillé pour tester sans démarrer FluxBox. J'ai reçu les mêmes résultats que la version NOOB que j'ai également testée sans l'interface graphique du bureau (démarre uniquement en mode console).

La raison pour laquelle j'ai fait référence au problème # 5348 est qu'il indique "symbole indéfini: glGetFramebufferAttachmentParameteriv" ​​et cela ressemble au message d'erreur que je reçois ci-dessous (et également ci-dessus dans mon message d'origine). Ces erreurs continuent de se produire jusqu'à ce que le GPU manque de mémoire et plante l'application de test.

Échec de l'initialisation FBO : pièce jointe incomplète (36054)

Aujourd'hui, je vais essayer d'activer la variable d'environnement Kivy GL Debug pour voir si je peux obtenir plus de détails lors de mes tests. On m'a également conseillé de revenir à une version antérieure de Cython car elle a provoqué des résultats similaires sur d'autres systèmes d'exploitation.

J'ai maintenant essayé plusieurs versions sans XWindows, deux versions de cython et un kivy reconstruit à l'aide des pilotes gl4es. Je continue à recevoir le message d'erreur suivant lors de l'exécution d'une simple application de test de screenmanager. Sous l'erreur FBO se trouvent les journaux de consommation de mémoire et Kivy OpenGL Debug lors de l'exécution de la même application.

Échec de l'initialisation FBO : pièce jointe incomplète (36054)

16 Go-Deb-screenmanagertest-memory-results.zip
Kivy-OpenGL-Debug-Log.zip

De Dark Photon sur OpenGL pour RPi, il a déclaré ce qui suit :

Le rapport de consommation de mémoire GPU que vous avez obtenu pendant que votre problème de "GPU en manque de mémoire" se produisait détaille clairement ce qui, sous le capot, consomme toute cette mémoire GPU. 480 Mo consommés avec seulement 5,4 Mo gratuits confirment certainement qu'il y a un problème !

Parmi les consommateurs de mémoire GPU répertoriés, il semble que les plus gros poissons soient :

• 310 Mo bloqués dans 39 images de 8 Mo (KHRN_IMAGE_T.storage)
• 105 Mo bloqués dans 17 ~ 6,3 Mo de texture blobs
• 53 Mo en 4 gouttes de texture de 13 Mo
• 7 Mo dans ARM FB
• 3,3 Mo en divers (code de shader/programmes, etc.)
  

  Référence : problème du forum OpenGL RPi

Vous trouverez ci-dessous un lien vers mon code que j'ai exécuté pour générer le journal de débogage OpenGL ci-dessus.
screenmanagertest.py.txt

Je voudrais proposer d'aider toute personne ayant ce problème à trouver une solution. Peut-être que quelqu'un pourrait se porter volontaire si j'offrais un Raspberry Pi 3 GRATUIT pour déboguer ce problème ? Je suis ouvert à toutes suggestions et recommandations à ce stade.

En fait, en regardant un peu plus loin dans le journal que vous avez joint dans votre premier message, il me semble que tout cela est causé par une API manquante liée aux shaders. Il indique : [DEBUG ] [GL ] glShaderBinary is not available et au bas de la trace de la pile : Exception: Shader didnt link, check info log.

De plus, la documentation indique (c'est moi qui souligne):

La prise en charge binaire du shader est facultative et doit donc être interrogée avant utilisation en appelant glGet avec les arguments GL_NUM_SHADER_BINARY_FORMATS et GL_SHADER_BINARY_FORMATS. glShaderBinary génère GL_INVALID_OPERATION sur les implémentations qui ne prennent en charge aucun format binaire de shader. De telles implémentations offrent à la place l'alternative glShaderSource pour fournir la source de shader OpenGL ES Shading Language pour la compilation.

Et maintenant, ma prochaine question (complètement mal informée) serait : Kivy est-il capable de remettre les shaders sous forme source, ou les binaires sont-ils obligatoires ?

Edit : Si mon intuition est bonne et que je regarde la source ( kivy/graphics/shader.pyx ), celles-ci sont automatiquement construites par Kivy, même dans la branche principale actuelle (je n'ai pas vérifié les anciennes versions) :

    property vs:
        '''Vertex shader source code.
        If you set a new vertex shader code source, it will be automatically
        compiled and will replace the current vertex shader.
        '''
        def __get__(self):
            return self.vert_src
        def __set__(self, object source):
            if source is None:
                source = default_vs
            source = source.replace('$HEADER$', header_vs)
            self.vert_src = source
            self.build_vertex()

Notez la dernière ligne. Je suppose que vous auriez besoin d'une version de ceci qui:

1. ne le construit pas automatiquement
2. utilise self.source et le transmet à un appel glShaderSource non encore implémenté
3. laisse probablement la source être compilée via OpenGL d'une manière ou d'une autre?
4. et seulement ensuite essaie de le lier

En bref: vous devrez probablement programmer vous-même une solution de contournement (uniquement si ma supposition est correcte, cependant).

Edit 2 : En fait, je vois des trucs sur la source de shader là-dedans, mais je n'ai pas encore l'image complète. C'est un peu inutile pour moi de toute façon, je ne peux pas le tester.

@franckould
Ce serait probablement un peu long, mais si vous êtes prêt à essayer de faire fonctionner QEMU (mentionné dans l'autre numéro), je vais passer du temps sur le canal IRC Kivy aujourd'hui - communiquer ici sur GitHub serait beaucoup trop encombrant.

Merci pour toute votre aide avec ce dolang. J'ai réussi à faire en sorte que QEMU exécute une petite construction img mais pas d'autres, comme KivyPie . La version que j'ai pu émuler provient du lien collé ci-dessous.

https://github.com/ccrisan/motioneyeos

Je vais faire plus de tests pour savoir comment afficher la console. Cette version avait très peu de contrôles. J'ai essayé la construction minimale de Raspian mais elle n'a pas réussi à charger le noyau. Je pense que je dois mettre à jour ma RAM de 4 Go à 8 Go.

Désolé, j'ai raté votre discussion sur le forum Kivy hier après-midi et merci beaucoup pour votre temps et vos efforts. Je ne suis pas pressé donc tout ce que vous pouvez faire est vraiment apprécié. J'ai également contacté le forum KivyPie et j'essaie de les amener à aider. Peut-être devrions-nous échanger des adresses e-mail lorsque nous ne sommes pas en ligne en même temps ?

Utilisez-vous des transitions de shader dans votre code ? Les transitions de shader ne fonctionnent pas de manière fiable avec le backend sdl. Heureusement, cela peut être résolu avec les bons pilotes d'affichage et les backends opengl. Je pense que j'ai eu le même problème il y a quelque temps, veuillez poster les 10 premières lignes de la sortie kivy où le pilote opengl et le backend sont affichés, peut-être que je peux vous aider.

Merci pro90 pour son aide. J'ai commencé à coller le début du journal, comme vous l'avez demandé, mais lorsque j'ai trouvé le journal joint, j'ai pensé que l'ensemble du journal d'exécution pourrait être utile, y compris le démarrage. À la fin, vous verrez où j'ai inséré ce qui s'est passé, c'est-à-dire que tout l'ordinateur était verrouillé et devait être redémarré pour redémarrer. Nous supposons une fuite de mémoire.

KivyPie-screenmanagertest-multi-pics-log.txt

Quant à est-ce que j'utilise des transitions de shader, je ne peux que le supposer, mais pas directement. J'utilise kivy screenmanager pour animer les transitions de diapositives. Je suppose que le code utilise des shaders.

J'apprécierais également toute formation que vous pouvez offrir ou site Web qui m'aide à comprendre comment ces pilotes et modules fonctionnent ensemble. Je ne sais pas comment ils interagissent entre eux et je comprends que certains sont des wrappers pour d'autres modules graphiques de base, comme OpenGL. On m'a également suggéré d'utiliser gl4es car c'est ce que les joueurs utilisent sur RPi. Je n'ai pas été en mesure de confirmer que c'est la bonne solution.

Merci encore!

en ce qui me concerne, vous n'utilisez pas de vrai matériel open gl. Votre moteur de rendu opengl doit être "Gallium 0.4 sur VC4 V3D 2.1". Tout d'abord, activez les pilotes Broadcom OpenGL : sudo raspi-config -> Options avancées -> "GL (Full KMS) OpenGL desktop driver with full KMS". Vous devez également ajuster la mémoire de la carte graphique partagée à au moins 64 Mo. Pour que cela fonctionne, vous devez utiliser un environnement de bureau, je suggère PIXEL. Vous avez également besoin des packages libgl1-mesa-dri et xcompmgr d'apt-get. Je suggère de partir d'une image rpi vanille. Faites-moi savoir si ces étapes fonctionnent !

Salutations à tous ceux qui regardent ce fil. J'ai passé de nombreuses heures à rechercher et à tester des environnements pour établir la bonne version du système d'exploitation afin d'isoler ce bogue qui finit par consommer toute la mémoire graphique et planter l'application Kivy.

Une fois que j'ai déterminé que toutes les versions Linux de Raspberry Pi présentaient ce même problème qui ne se produisait PAS sur Oracle VM Mint Linus (pas de messages glGetError), j'ai commencé à ajouter des messages de débogage dans shader.pyx qui m'ont permis d'isoler où certaines actions causant un glGetError 0x502 (invalide Operation) que je soupçonnais d'avoir causé les éventuelles erreurs 0x505 hors mémoire.

Ce que j'ai trouvé était un "uniforme" nommé "t" qui passait une valeur nulle (c'est-à-dire 0) immédiatement avant qu'une opacité nommée uniforme ne soit téléchargée. Voici ce que j'ai trouvé dans les journaux.

[DEBUG ] [Shader ] téléchargement uniforme t (loc=2, valeur=0)
[DEBUG ] [Shader ] téléchargement de l'opacité uniforme (loc=1, value=1.0)
glGetErreur 0x502
[DEBUG ] [Shader ] -> (gl:1282) opacité

Cela m'a incité à changer shader.pyx pour ignorer ces uniformes « t0 » invalides et l'application a cessé de générer les erreurs glGetError 0x502 ; cependant, cela n'a pas arrêté la "fuite de mémoire" car finalement, comme en 10 minutes, l'application s'est écrasée avec les messages d'erreur 0x505 puis 0x506 (opération de tampon de trame invalide - même erreur FBO dans les entrées du journal Kivy). Je pense que c'est aussi la raison pour laquelle shader.pyx signale 'Exception: Shader n'a pas lié, vérifiez le journal des informations' car il n'y a pas de mémoire à lier.

Donc, maintenant, j'ai collecté plusieurs journaux d'exécution qui montrent l'utilisation de la mémoire pendant la période où les messages d'erreur 0x505 s'affichent sur la console. Vous trouverez ci-dessous les résultats lors de l'exécution de 'vcdbg reloc' lorsque ces messages d'erreur 0x505 de la console sont affichés (voir le journal d'exécution nommé vcdbg reloc - Fresh Boot18Mar-crashingwithGC.txt pour un instantané complet).

9,8 Mo de mémoire libre dans 9 bloc(s) libre(s)

Parmi les nombreuses entrées (comme les deux ci-dessous avec les valeurs entre parenthèses supprimées), ces deux semblent être les candidats à la consommation de mémoire majoritaire. La quantité utilisée varie tout au long du journal.

[ 336] 0x375bf740 : utilisé 6,3 M 'Texture blob'
[ 840] 0x37c03760 : utilisé 1,5 M 'KHRN_IMAGE_T.storage'

Ensuite, dans une section, j'ai trouvé les messages d'erreur suivants.

0x2c570da0 : bande-annonce corrompue (espace -256 != 1572961)
0x2c570da0 : bande-annonce corrompue (guards[0] = 0xffffff00)
0x2c570da0 : bande-annonce corrompue (guards[1] = 0xffffff00)
0x2c570da0 : bande-annonce corrompue (guards[2] = 0xffffff00)
0x2c570da0 : bande-annonce corrompue (guards[3] = 0xffffff00)
0x2c570da0 : bande-annonce corrompue (guards[4] = 0xffffff00)
0x2c6f0e00 : entrée corrompue (espace 0xffffff00)
resynchronisé à 0x2c6f0fe0 (sauté 480 octets)

Je ne sais pas quoi faire ensuite, à part lire le journal de débogage du runtime GL pour voir si je peux trouver ce qui se passe dans OpenGL et comment le réparer dans Kivy ou je peux essayer de comprendre ce que fait screenmanager quand ça pose problème les commandes OpenGL (ou tout autre téléchargement uniforme obtenu). Mon problème est de ne pas savoir comment fonctionnent ces couches graphiques sous Kivy et lesquelles pourraient être suspectes.

Vous trouverez ci-dessous un récapitulatif d'autres suggestions de forums :

1. vcgencmd get_mem gpu a toujours renvoyé 512, ce que j'ai défini dans la configuration RPi.
2. Il existe des transitions de gestionnaire d'écran qui ne présentent pas cette même erreur 0x502 mais qui finissent par afficher glGetError 0x505 avec peu de mémoire libre.
3. J'ai tenté ces tests avec différentes images avec seulement deux fichiers jpg (voir ci-dessus) en basse résolution mais les mêmes résultats se produisent finalement avec 0x505.
4. Je n'ai pas pu libérer la mémoire GPU (testée avec vcdbg reloc) en utilisant echo # > /proc/sys/vm/drop_caches.
5. Vous avez obtenu les mêmes résultats après avoir changé les graphiques RPi en GL Driver (Full KMS) dans raspi-config-> Advanced-> GL Driver.
6. J'ai obtenu les mêmes résultats après l'installation de gl4es, libgl1-mesa-dri et xcompmgr.
7. Génération d'un énorme journal de console OpenGL Debug Kivy en temps réel (> 60 000 lignes) qui affiche de nombreuses erreurs GL internes. Cela a été activé en utilisant os.environ['KIVY_GL_DEBUG'] = '1' dans l'application Kivy.

Choses à essayer pour aller de l'avant :

1. Terminez la configuration de QEMU pour permettre aux autres de voir l'exécution à dupliquer et peut-être corriger. Je l'ai fait fonctionner mais tout ce que je vois est un écran noir et quelques onglets facultatifs qui se comportent étrangement.
2. Trouvez un moyen de 1) libérer de la mémoire, 2) réparer shader/screenmanager, 3) obtenir une assistance de développement, 4) examiner le journal pour trouver le module provoquant une fuite de mémoire.

Vous pouvez afficher la console de démarrage Kivy pour voir ce qui commence au lancement de l'application.

Toute autre suggestion sera grandement appréciée par tout le monde.

Ce n'est pas grand-chose (car la plupart des questions ne relèvent pas de mon expertise), mais peut-être que cela vous aidera ?

Il existe des transitions de gestionnaire d'écran qui ne présentent pas cette même erreur 0x502 mais qui finissent par afficher glGetError 0x505 avec peu de mémoire libre.

certaines transitions ne sont pas basées sur le shader, cela pourrait en être la raison. ( NoTransition , SlideTransition et SwapTransition ) -> vous avez mentionné plus tôt que vous avez utilisé SlideTransition , qui compense simplement son contenu en utilisant les instructions kivy régulières, pas de shader spécifique .

[DEBUG ] [Shader ] téléchargement uniforme t (loc=2, valeur=0)

cela pourrait être un rien, mais je suis surpris que cela soit indiqué "0" et non "0.0" ici, la valeur devrait certainement être un flotteur, et le passage d'un int pourrait provoquer le problème "le shader n'a pas lié", bien que cela devrait être résolu dès que la transition progresse vers la version 1.0.

Merci tshirtman pour votre réponse. J'ai effectué quelques tests supplémentaires pour confirmer ce que vous avez publié et j'ai appris que ceux que vous avez signalés comme n'étant pas basés sur le shader (c'est-à-dire SwapTransition) apparaissent dans le journal KIVY_GL_DEBUG et affichent également les messages glGetError 0x505. Cela a juste pris plus de temps.

J'ai joint une copie du journal lors de l'utilisation de la journalisation de débogage SwapTransition et Kivy pour montrer ce qui se passe dans le téléchargement de l'uniforme du shader. J'ai également joint un journal FadeTransition montrant que les Shaders Vector et Fragment sont compilés lors du lancement, puis Fragment Shader est à nouveau compilé plus tard, après le démarrage de la boucle principale de l'application.

Quant à la valeur t uniforme étant un flotteur, j'ai changé sa valeur dans shader.pyx et voici ce que le journal a rapporté ci-dessous. Donc, je suppose que pour cette erreur 0x502 causée par t value = 0, je devrais simplement ignorer son téléchargement comme je l'ai codé pour le faire. Je n'ai pas vu de corrélation dans la consommation de fuite de mémoire, donc je suppose que ce n'est pas lié.

[ERREUR ] [Shader ] conversion uniforme t avec valeur=0
[ERROR ] [Shader ] a converti l'uniforme t avec la valeur=0.0
glGetErreur 0x502
[ERREUR ] [Shader ] conversion uniforme t avec valeur=0
[ERROR ] [Shader ] a converti l'uniforme t avec la valeur=0.0
glGetErreur 0x502

J'apprécie vraiment toute autre suggestion ou idée. Tout petit geste aide.

SwapTransition-using-shader-debuglog.txt
FadeTransition-using-shader-debuglog.txt

@frankgould Pourriez-vous essayer de tirer le maître et voir si vous avez toujours le problème ou non?
Sinon, pouvez-vous essayer de donner un exemple exécutable qui montre le problème sans aucune intervention de l'utilisateur ? (comme cliquer sur un bouton).

Si possible, essayez de suivre https://gist.github.com/tito/1174b86ce126fd1ac11afbc77750d9ac - Ceci a été écrit ce matin et j'ai trouvé une fuite dans Fbo/renderbuffers. Le correctif est validé dans master, ce script peut-il vous aider à en trouver plus dans votre logiciel ?

Après lecture du log, de mon point de vue, tout venait du nombre d'images chargées. À un moment donné, la façon d'écrire votre application consommera simplement de la mémoire. Je veux dire, si vous n'avez que 3 images, ça marche non ?
Mais si vous en avez plus, alors vous avez des problèmes.

Kivy/Python ne peut pas gérer la mémoire de la même manière que vous. Je suppose que vous auriez besoin de réécrire un algo pour ne garder que 3 "grosses" images en mémoire "actuelle, suivante, précédente par exemple" (même garder l'image actuelle chargée, et toujours libérer la précédente), et libérer toutes les précédentes . De cette façon, vous avez le contrôle et moins de chances d'atteindre cette limitation.

Si vous utilisez "Screen", vous pouvez utiliser un événement comme on_pre_enter pour charger l'image, on_leave pour la libérer

Merci beaucoup Tito pour votre aide sur ce problème. J'ai exécuté l'application de test de diaporama screenmanagertest.py pendant la nuit et la mémoire est restée constamment sans fuite ni erreur. C'était un soulagement à voir.

Je voulais également signaler que j'ai ajouté quelques lignes de code dans le module Shader.pyx pour corriger un appel t uniforme avec une valeur de zéro qui a généré des messages glGetError 0x502. Vous trouverez ci-dessous le git diff de ma modification qui a supprimé les erreurs glGetError 0x502.

diff --git a/kivy/graphics/shader.pyx b/kivy/graphics/shader.pyx
index 53286893..67e8eab7 100644
--- a/kivy/graphics/shader.pyx
+++ b/kivy/graphics/shader.pyx
@@ -265,6 +265,9 @@ cdef class Shader:
         if loc == -1:
             #Logger.debug('Shader: -> ignored')
             return 0
+        if name == 't' and value == 0:
+            #Logger.debug('Shader: -> t:0 ignored')
+            return 0
         #Logger.debug('Shader: -> (gl:%d) %s' % (glGetError(), str(value)))

         if val_type is Matrix:

En ce qui concerne le code de test dont vous avez parlé, il ne s'agissait que d'un exemple de code que j'ai trouvé en ligne pour m'éviter de supprimer mon énorme code pour tester screenmanager. Mon code gère les écrans comme vous l'avez suggéré. Je vais travailler sur la migration de mon application de diaporama aujourd'hui pour confirmer qu'elle est également opérationnelle.

Je dois également mentionner que votre suggestion d'utiliser apitrace n'a pas fonctionné dans l'environnement RPi et j'ai joint une copie du journal de la console de lancement pour examen. J'ai obtenu les mêmes résultats avec dolang et mes applications de test, mais je ne savais pas quoi faire pour résoudre ce problème. J'ai dû installer apitrace deux fois sur ce RPi car les deux installations n'ont pas réussi à charger un fichier gltrace.conf à exécuter. J'en ai trouvé un affiché en ligne (également joint) et je ne l'ai pas changé.

Je vais également publier un commentaire sur les deux problèmes github suivants pour leur faire savoir qu'il existe une nouvelle version de context.pyx à extraire.

https://github.com/kivy/kivy/issues/4662
https://github.com/kivy/kivy/issues/4542

S'il vous plaît laissez-moi savoir si quelqu'un a des suggestions concernant ce poste à l'avenir. Merci encore pour votre temps et votre aide à ce sujet.

gltrace.conf.txt

apitrace-console-log.txt

Non, le problème concernant name == "t" et la valeur 0 est un non. Avoir une erreur n'est pas un gros problème, mais oui, nous devrions l'éviter. C'est une question d'initialisation du shader avant l'ensemble de la valeur, peut-être que quelques retouches sont nécessaires, mais faire un tel patch casse en fait n'importe qui d'autre qui a un shader avec t uniforme et la valeur 0 :)

Encore une fois, ces erreurs pourraient être évitées, mais c'est "ok" pour le moment car cela n'a aucun impact.

Je sais que c'est un problème clos, mais je vais également publier un message ici. Je reçois le crash redouté "ERROR - Shader: GL error 1281" ainsi que "Exception non interceptée (échec de l'initialisation FBO)" sur un Pi3B avec Kivy 1.10.1 avec gpu_mem=376 si j'essaie de faire plusieurs root.export_to_png() est trop rapproché. Si l'utilisateur se comporte bien et n'essaie pas de parcourir l'interface du menu (en lançant parfois des événements de capture d'écran), alors il se comporte.

Cela semble être lié à l'existence de corruption à la fin de sudo vcdbg reloc et failed allocs comme on le voit dans sudo vcdbg malloc .

Au cours des derniers mois de développement (qui ajoutent de plus en plus de graphismes), j'ai dû bousculer les gpu_mem un peu à la fois pour suivre la corruption. (Et bien sûr, je garde maintenant un œil sur l'utilisation de l'espace d'échange puisque 1 Go de RAM est une ressource finie.) Une fois que le Pi4B est en cours d'exécution, je peux lancer le gpu_mem jusqu'à un filigrane élevé sans m'inquiéter. beaucoup.

Enfin, je dirai que les paramètres de mise en cache de Kivy pourraient en théorie supprimer certaines des textures, par exemple, hors de la mémoire GPU de temps en temps.