Je développe une application graphique Java avec jogl et OpenGL sous Linux. Mon application contient plus de 30 shaders et ils fonctionnent bien dans la plupart des cas. Mais environ une fois par semaine il y a une erreur de pilote (amdgpu pro) (SIGSEGV). Se il vous plaît dites-moi, est OpenGL langue sûre: Il est protégé contre les erreurs par le programme d'application ou des actions incorrectes de l'application peuvent endommager la mémoire du pilote (écrire dans la mémoire ou la course de données de quelqu'un d'autre). Dans quoi puis-je chercher la cause de l'erreur (SIGSEGV) dans le pilote incorrect (amdgpu pro) ou dans les erreurs de l'application elle-même? (Le glGetError montre que tout va bien à chaque étape de l'application).L'API OpenGL 4.3 et le langage glsl sont-ils sécurisés?
Répondre
En général, il y aura de nombreuses façons de planter votre programme lorsque vous utilisez l'API OpenGL. Les pilotes de buggy sont une réalité malheureuse que vous ne pouvez pas éviter complètement, et une mauvaise utilisation de l'API de manière créative peut provoquer des plantages au lieu d'erreurs. En fait, j'ai personnellement causé le blocage complet des ordinateurs (sans réponse) sur plusieurs plates-formes et différents fournisseurs de GPU, même en utilisant WebGL qui est censé être "sûr".
Donc la seule réponse possible est "non, OpenGL n'est pas sûr".
Quelques conseils pour OpenGL débogage:
Ne pas utiliser la
glGetError, utilisezKHR_debugà la place (à moins que ce n'est pas disponible).Créez un contexte de débogage avec
GL_CONTEXT_FLAG_DEBUG_BIT.Utilisez une implémentation OpenGL moins buggée lorsque vous testez. Dans mon expérience, l'implémentation de Mesa est très stable.
sérieusement, fortement envisager de se débarrasser de tous les appels 'glGetError' en faveur de' KHR_debug'. 'KHR_debug' vous donnera les mêmes informations que' glGetError' et, s'il est configuré pour, vous permettra de configurer des points de rupture quand l'erreur est survenue, où 'glGetError' signifie simplement que l'erreur s'est produite avant qu'elle ne soit appelée. – tamato
OpenGL 4.3 est-il "sûr"? Absolument pas. Il y a beaucoup de choses que vous pouvez faire qui peuvent planter le programme. Avoir une opération de rendu lire de passé les limites d'un tampon, par exemple. 4.3 a beaucoup de façons de le faire.
En effet, écrire simplement un shader qui s'exécute trop longtemps peut provoquer une panne du GPU.
Vous pourriez en théorie lire la mémoire GPU qui a été écrite par une autre application, juste en lisant à partir d'un tampon non initialisé.
Il n'existe aucun moyen simple de savoir si un plantage particulier a été causé par un bogue du pilote ou par une erreur de l'utilisateur. Vous devez réellement le déboguer et avoir une compréhension de la spécification OpenGL pour être sûr.
OpenGL n'est pas une langue. L'implémentation du pilote est juste un programme qui peut contenir des bogues. Une utilisation incorrecte ou non standard de l'API peut potentiellement provoquer des plantages. –
Quelles sont les actions de l'application qui peuvent provoquer un plantage du pilote (SIGSEGV) s'il n'y a pas d'erreur évidente et où glGetError indique qu'il n'y a pas de problème? Existe-t-il des outils de débogage pour détecter automatiquement ces actions incorrectes? –