[SFML 2] impossible de rendre 2 fenetres (linux mesa gallium r600) [Contourné]

[lefta]

Bonojur,

En créant un éditeur de cartes pour un jeu, je me suis rendu compte qu'il métait impossible de créer deux fenêtres de rendu dans une application wxWidget. Le rendu de la première ou de la deuxième fonctionne, mais quand j'affiche les deux, la deuxième ne s'affiche pas.
Au redimensionnement, j'obtiens du "bazar" (je ne vois pas d'autres mots). On dirait qu'elle affiche le contenu de la memoire non modifié (comme si la fonction onUpdate() n'était pas utilisée), étant donné que parfois, cette fenêtre affiche des "bouts" de l'application (de menus, de la barre de titre, de l'autre canvas...).
Lancé en console, je me suis rendu compte que celà provoquait une erreur du driver :

radeon 0000:01:00.0: texture bo too small (384 480 26 0 -> 737280 have 4096)
radeon 0000:01:00.0: alignments 384 1 1 1
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

Le même code sous Windows 7 fonctionne.

D'autres ont eu le problème avec l'exemple des shaders : https://bugs.freedesktop.org/process_bug.cgi

Donc cela vient-il d'un bug du driver linux, ou d'une mauvaise implémentation de la partie linux ? 

PS : Dans les conditions d'utilisation du forum, je crois qu'il y a une faute :
"de l'équipe, DE ses filiales, ou du propriétaire du forum"
et non "de l'équipe, DES ses filiales, ou du propriétaire du forum",
dans le 2eme paragraphe il me semble 

EDIT : Pour résumer, c'est un bug venant des drivers mesa gallium r600 (concerne les chipsets r600, r700, Evergreen et Northern Island). Celà semble aussi poser souci si on charge une texture avant d'ouvrir une fenetre.
Pour suivre le rapport de bug :  ici
Pour un conternement vite fait bien fait, au détriment des performances graphiques : ici

[Laurent]

Donc cela vient-il d'un bug du driver linux, ou d'une mauvaise implémentation de la partie linux ?

Très honnêtement je n'en sais rien. Il faudrait tester deux fenêtres SFML natives (sans wxWidgets) : si ça marche alors SFML sera hors de cause. Enfin... si ça ne marche pas ça pourra quand même être un bug de driver

"de l'équipe, DE ses filiales, ou du propriétaire du forum"
et non "de l'équipe, DES ses filiales, ou du propriétaire du forum",
dans le 2eme paragraphe il me semble

C'est pas à moi qu'il faut dire ça, c'est aux développeurs de SMF (ou aux traducteurs FR)

[lefta]

Il faudrait tester deux fenêtres SFML natives (sans wxWidgets)

Je vais tester, je te tiens au courant 

Sinon très efficace ta réponse

EDIT : Même problème avec 2 fenetres de rendu sans wxWidgets (testé dans le code du jeu). Existe-t-il une façon de mettre en cause SFML ou le driver?

[Laurent]

Tu peux poster un code complet minimal qui reproduit le problème, et j'essayerai de tester ça.

[lefta]

Voila. Je précise que dans ce code, on n'utilise qu'un seul sprite et une seule texture, mais dans mon code j'en ai mit deux pour tester. (même s'il s'agit de la même image)

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow Bug(sf::VideoMode(800, 600), "SFML bugging window");
    sf::RenderWindow App(sf::VideoMode(800, 600), "SFML window");

    sf::Texture texture;
    if (!texture.loadFromFile("cb.bmp"))
        return EXIT_FAILURE;
    sf::Sprite sprite(texture);

    while (App.isOpen())
    {
        sf::Event event;
        while (App.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
            {
                Bug.close();
                App.close();
            }
        }

        Bug.clear();
        App.clear();

        Bug.draw(sprite);
        App.draw(sprite);

        Bug.display();
        App.display();
    }
    return EXIT_SUCCESS;
}
 

EDIT : Même s'il s'agit de deux images différentes le bug est présent

[Laurent]

Et si tu mets une boucle d'évènements aussi sur la seconde fenêtre ?

[lefta]

Idem, ça m'aurait étonné que ça change quoi que ce soit de toutes façons 

[Laurent]

Ca change beaucoup de choses : une fenêtre sans boucle d'évènements sera gelée, pas réactive. Donc on peut très bien imaginer que ça gèle aussi l'affichage avec certains système.

Peux-tu poster le code corrigé, juste pour être sûr que je teste bien la même chose que toi ?

[lefta]

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow Bug(sf::VideoMode(800, 600), "SFML bugging window");
    sf::RenderWindow App(sf::VideoMode(800, 600), "SFML window");

    sf::Texture texture;
    if (!texture.loadFromFile("cb.bmp"))
        return EXIT_FAILURE;
    sf::Sprite sprite(texture);

    while (App.isOpen())
    {
        sf::Event event;
        sf::Event event2;
        while (App.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
            {
                Bug.close();
                App.close();
            }
        }

        while (Bug.pollEvent(event2))
        {
            if(event2.type == sf::Event::Closed)
            {
                Bug.close();
                App.close();
            }
        }


        Bug.clear();
        App.clear();

        Bug.draw(sprite);
        App.draw(sprite);

        Bug.display();
        App.display();
    }
    return EXIT_SUCCESS;
}
 

PS : J'ai une machine virtuelle windows XP, dans laquelle ça ne fonctionne qu'à moitié : le deuxième contrôle est rafraichi, mais plutôt que d'afficher les tiles de ma map, ça affiche des carrés blancs. Mais s'il s'agit d'un bug du driver, il se peut que la VM en hérite non?

[lefta]

Alors Laurent, tu as du nouveau? Tu as réussi à reproduire le bug ou pas? 

[Laurent]

J'ai pas eu le temps d'essayer, désolé.

[lefta]

Si ça peut avoir un rapport, j'ai une ati mobility radeon hd 4570 

EDIT : /var/log/Xorg.0.log :

[  3117.824] (II) RADEON(0): EDID vendor "AUO", prod id 4333
[  3117.824] (II) RADEON(0): Printing DDC gathered Modelines:
[  3117.824] (II) RADEON(0): Modeline "1920x1080"x0.0  134.40  1920 1950 1970 1982  1080 1090 1100 1130 +hsync -vsync (67.8 kHz eP)
 

EDIT 2 : C'est au moment du draw() que le bug se présente. Commenter Bug.draw() "supprime" le bug

EDIT 3 : J'ai supprimé la vérification entraînant le message d'erreur dans les sources du kernel, j'obtient un affichage presque noir avec quelque lignes bleues, pas du tout mon image. J'ai donc deux hypothèses :
- Le noyau linux n'arrive pas à gérer la deuxième fenêtre correctement
- SFML fait une erreur en passant la deuxième image au driver

Ce qui me donne une idée : est-ce que cela fonctionnera si la deuxième fenetre est dans un autre thread?

[lefta]

Je viens de trouver un moyen de contourner le problème : il suffit de lancer la deuxième fenêtre dans un thread.
Un code d'exemple :

#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

void fenetreBug()
{
    sf::RenderWindow Bug(sf::VideoMode(800, 600), "SFML bugging window");

    sf::Texture texture;
    if (!texture.loadFromFile("cb.bmp"))
        return;
    sf::Sprite sprite(texture);

    while (Bug.isOpen())
    {
        sf::Event event;
        while (Bug.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
            {
                Bug.close();
            }
        }
        Bug.clear();
        Bug.draw(sprite);
        Bug.display();
    }
}

int main()
{
    sf::RenderWindow App(sf::VideoMode(800, 600), "SFML window");

    sf::Texture texture;
    if (!texture.loadFromFile("cb.bmp"))
        return EXIT_FAILURE;
    sf::Sprite sprite(texture);

    sf::Thread thread(&fenetreBug);
    thread.launch();

    while (App.isOpen())
    {
        sf::Event event;
        while (App.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
            {
                thread.wait();
                App.close();
            }
        }

        App.clear();
        App.draw(sprite);
        App.display();
    }
    return EXIT_SUCCESS;
}
 

Je ne connais toujours pas la source du problème, mais maintenant, Laurent pourra se concentrer sur d'autres bugs avant de se pencher sur celui là

[Laurent]

Ouais, c'est étrange

[lefta]

Ça c'est ma spécialité : poser le problème ou trouver le bug à la con auquel personne n'a réponse