QT 5.0.0 version opengl supportée

Version imprimable

20/12/2012, 17h06
el goupil

QT 5.0.0 version opengl supportée
Bonjour a tous !

je suis dans l'exploration de QWindow dans QT 5.0.0 en utilisant les précieuses information suivantes :
http://qt.developpez.com/actu/49471/...rne-dans-Qt-5/

je me suis aperçu que qt 5.0.0 renvoie toujours la version opengl ES 2.0 et j'ai donc essayé de changer tous les paramètres pour travailler avec une autre version opengl mais sans succès.
Voici ci dessous le code correspondant :
Code:

1 2 3 4 5 6 QSurfaceFormat format; format.setDepthBufferSize( 24 ); format.setMajorVersion( 3 ); format.setMinorVersion( 3 ); format.setSamples( 4 ); format.setProfile( QSurfaceFormat::CoreProfile );
En faisant une recherche je suis tombé sur ce lien :
http://qt-project.org/forums/viewthread/20424

Donc il s'agit d'un bug au niveau du module QtOpengl.

1 - DONC QT 5 ne fonctionne qu'avec 1 seule version Opengl?
2 -suivant le lien ci-dessus cela veux dire qu'il faut recompiler qt en remplaçant le fichier contenant le bug?
3 - s'il faut recompiler, cela dépasse pour le moment mes compétences quelqu'un aurait une info sur cette dernière question.?
Merci
20/12/2012, 22h31
gbdivers

Il y a eu effectivement une régression par rapport au support d'OpenGL dans Qt, du fait du passage au nouveau systèmes d'abstraction de la plateforme (QPA). La politique à un peu changer, le but pour Qt 5.0 est surtout de fournir le support d'OpenGL pour les besoins internes de Qt plutôt que pour les utilisateurs de Qt.
Du coup, le support de Qt s'est surtout orienté vers ES (support de Qt sur les plateformes mobiles oblige), retrait des shaders géométriques, retrait de Qt3D, etc.
Il est prévu un support complet d'OpenGL 4.3 dans Qt 5.1, soit dans QtGui, soit dans Qt3D qui sera a nouveau intégré dans les libs
Pour le moment, pour OpenGL, je conseille de rester sur Qt 4

EDIT : petite correction suite à un post de Sean Harmer : http://qt-project.org/forums/viewthread/22821/#107114
Le support d'OpenGL sera rétablit dans la version mingw de Qt, donc dans Qt 5.0.1, qui sort en janvier
(décidément, j'ai beaucoup de mal à comprendre le choix de mettre la priorité sur MSVC au lieu de gcc sur window)
21/12/2012, 09h02
RapotOR

En fait, la version Qt5 déjà compilée pour windows utilise Angle (et support directx). De ce que j'ai cru comprendre, c'est OpenGL ES2 qui sert au pont avec angle. Et comme dit plus haut, si tu developpes en OpenGL ES2, tu pourras plus facilement aller vers le mobile.

Si par contre; le mobile ne t'interresse pas, si tu veux le support de OpenGL, tu dois compiler Qt5 avec l'option "-opengl desktop". De mémoire, il y a néanmoins un support à partir de OpenGL 2.1 (donc 2.1 ou +); je vais tenter de retrouver la source de ce propos.

http://blog.qt.digia.com/blog/2012/1...fferent-angle/

Citation:

On the other hand if your application requires full desktop OpenGL, then it’s simply a matter of configuring Qt with “-opengl desktop” and you get the same behavior as before.

Je suis justement en train de compiler Qt5 avec MinGW 4.7 en suivant ceci: http://qt-project.org/wiki/MinGW-64-bit
L'adresse est indiquée 64bit mais la procédure est la même.

Comme j'ai quand meme galéré, je vous donne ce que j'ai utilisé (pas de openssl, pas icu, pas angle):

Citation:

cd C:\QtSDK\Qt5
set INCLUDE=
set LIB=
set QMAKESPEC=
set QTDIR=
set PATH=%CD%\qtbase\bin;%CD%\gnuwin32\bin;C:\Qt\mingw\bin;C:\Perl\bin;C:\Python27;%SystemRoot%\System32
set MAKE_COMMAND=

configure -debug-and-release -opensource -confirm-license -platform win32-g++ -developer-build -c++11 -opengl desktop -no-openssl -plugin-sql-sqlite -qt-style-windowsxp -qt-style-windowsvista -nomake tests -nomake examples

mingw32-make

Edit:
Pensez à virer les deux répertoires de Webkit. Il ne compile actuellement pas avec mingw. Ce serait la raison de la non-disponibilité du package mingw.
21/12/2012, 09h39
el goupil

Merci pour ces éclaircissements. Je comprend mieux la volonté de Qt 5 vis à vis de l'OpenGL.
En regardant l'OpenGL ES 2.0 , cette version offre pas mal de possibilité et garde l'avantage d'être "plus" portable.
Si la sortie de la version 5.0.1 est proche, pour ma part je vais laisser de côté la re-compilation de Qt et travailler avec Qt 4 ( ... car re-compiler c'est toujours un peu :aie: donc merci rapotor pour les infos sur ce sujet, je les garde sous le coude ca pourrait servir.)
21/12/2012, 14h43
ness522

Citation:

Envoyé par gbdivers

(décidément, j'ai beaucoup de mal à comprendre le choix de mettre la priorité sur MSVC au lieu de gcc sur window)

Qt commercial oblige, tu peux être sûr que la plupart des utilisateurs commerciaux utilisent MSVC.

D'un autre côté explique moi l'intérêt d'un port gcc sur windows alors que MSVC est disponible gratuitement ? (si ce n'est pour des raisons philosophiques, que je respecte mais je cherche les raisons techniques ici :p)
21/12/2012, 16h31
koala01

Salut,

Citation:

Envoyé par ness522

D'un autre côté explique moi l'intérêt d'un port gcc sur windows alors que MSVC est disponible gratuitement ? (si ce n'est pour des raisons philosophiques, que je respecte mais je cherche les raisons techniques ici :p)

Heu...

Toute considération philosophique mise à part :question:

Je ne vois qu'une raison qui pourrait passer presque inaperçue, tant elle est mineure : l'exécrable support de la norme que peut avoir MSVC au regard de ses concurrents à version similaires...

Sans blagues: si tu t'intéresses un peu ne serait-ce qu'aux nouvelles fonctionnalités de C++, à celles qui ne sont pas encore disponibles même pour MSVC2012 et que tu les compares à ce qui est disponible ne serait-ce qu'avec Gcc 4.6, il n'y a clairement pas photo ;)

Alors, bien sur, on attend avec impatience le portage de CLang sous windows, car il bat Gcc à plat de couture, mais bon, comme il est pas disponible... :aie:
21/12/2012, 18h46
gbdivers

@ness522
Pour la raison évoqué dans d'autres discussions sur l'installation de Qt : MSVC (a priori, j'en suis pas spécialiste, c'est la raison invoquée) autorise inclure dans une SDK un "redistribuable" (à prononcer à l'anglaise), qui autorise l'exécution d'un programme compilé avec MSVC, mais mais d'inclure le compilateur MSVC dans le SDK de Qt. Du coup, jusque maintenant, le SDK de Qt 5 n'était utilisable directement après installation (ça a peut être changé dans la version finale ?), il fallait installer en plus MSVC express (ce qui a posé beaucoup de problème aux débutants), contrairement à gcc qui était inclue dans le SDK.

Ensuite, c'est des considérations techniques. J'aime pas devoir écrire du code de shader différent pour OpenGL et DirectX (Angle). Et je préfère ne pas devoir apprendre l'utilisation avancée (options de compilation, support de C++11) de plusieurs compilateurs (je peux utiliser gcc suis windows, mais pas MSVC sous linux)
J'imagine qu'il doit y avoir d'autres problématiques, mais j'utilise pas assez MSVC pour tout voir ce qui me convient pas (c'est un choix perso, pas une argumentation pour convaincre les gens d'utiliser gcc)

Petit retour d'expérience, je viens de porter un gros projet (SpectraLayers) de Qt 4.8/MinGW/OpenGL à Qt 5.0/MSVC/OpenGL ES. Le tout sous Qt Creator.

Le passage de Qt 4.8 à Qt 5.0 n'a pas été une grosse difficulté: quelques fonctions ont été déplacés de classe, et certaines classes ont été renommés, mais grosso modo c'est allé assez vite (98% du code est resté tel quel).
Il faut juste piger que le partitionnement des modules n'est plus le même, par exemple les widgets ne font plus partie du module Gui mais du nouveau module Widget, et donc changer quelques headers globeaux/librairie Qt necessaire au projet.
Pour ceux qui créent des plugins, la déclaration des plugins a aussi légèrement changé, on passe de Q_EXPORT_PLUGIN2 à Q_PLUGIN_METADATA (qui n'ont pas exactement les mêmes paramètres).
A noter aussi la disparition de setAlphaChannel, il faut recréer son propre équivalent.

Le passage de MinGW à MSVC a été un peu plus compliqué, par exemple j'avais quelques sous-projets dans mon code principal qui n’étaient pas compris par MSVC, j'ai du simplifier la structure du projet en transformant mes sous projets du code principal en projets de librairies statique de meme niveau que le projet principal, et lier ces librairies statique à mon code principal.
Il a fallut d'autre part convertir certaines directives de compilation et de déclaration de fonctions propres à gcc, mais j'en avais peu dans mon code. Pour faire la distinction, dans le code c++ j'ai des:

Code:

#ifdef __GNUC__

Et dans mon projet .pro:
Code:

1 2 win32-g*|mac:QMAKE_CXXFLAGS += ... win32-msvc*:QMAKE_CXXFLAGS += ...
Il y avait aussi quelques warnings qui sont apparus, mais juste des problèmes mineurs.
Au niveau des perfs c'est à peu près équivalent, voire même un peu gagnant par endroit, par contre j'ai remarqué que MSVC gérait mal l'optimisation de boucles for(;;) compliqués, j'ai du remplacer certaines boucles critiques par un déroulement while(count--) { } simplifié pour retrouver de bonnes perfs (ceci dit j'aurai certainement gagné aussi un peu en perf avec MinGW je suppose).

Enfin, le passage de OpenGL à OpenGL ES a été vraiment galère. Mais quelque part c'est un mal pour un bien, dans la mesure ou OpenGL ES est une version simplifié d'OpenGL ça oblige à repenser de manière un peu plus simple sont code OpenGL (je faisais jusque là allègrement usages de tricks OpenGL en tout genre, y compris de fonctions obsolètes). Heureusement le framework Qt est la pour nous accompagner dans le développement OpenGL ES en fournissant quelques fonctions qui font gagner du temps.
Je dois souligner d'ailleurs que j'ai fait en sorte que mon nouveau code soit compatible à la fois avec OpenGL ES et OpenGL, dans la mesure ou Qt 5 sur mac (mon logiciel est compilé sur mac aussi) utilise toujours OpenGL.
Pour cela, dans mes shaders j'ai rajouté l'entête suivante:
Code:

1 2 3 #ifdef GL_ES precision highp float; #endif
Et j'ai créé le header suivant pour avoir certaines fontions/variables compatibles GL/GL ES:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 #ifndef GLESCOMP_H #define GLESCOMP_H //OpenGL/ES2 Compatibility #include <QtOpenGL> #ifdef QT_OPENGL_ES_2 #define GLENABLETEX2D #define GLRGBA32F GL_RGBA #define GLALPHA32F GL_ALPHA #define GLLUMINANCE32F GL_LUMINANCE #else #define GLENABLETEX2D glEnable(GL_TEXTURE_2D); #define GLRGBA32F GL_RGBA32F_ARB #define GLALPHA32F GL_ALPHA32F_ARB #define GLLUMINANCE32F GL_LUMINANCE32F_ARB #endif #endif // GLESCOMP_H
A noter que la signification des paramètres de textures en OpenGL ES n'est pas la même qu'en OpenGL ! Pour envoyer des textures float en OpenGL le code est le suivant:
Code:

1 2 3 4 glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, width, height, 0, GL_RGBA, GL_FLOAT, data); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F_ARB, width, height, 0, GL_RGBA, GL_FLOAT, data); glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA32F_ARB, width, height, 0, GL_ALPHA, GL_FLOAT, data); glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA16F_ARB, width, height, 0, GL_ALPHA, GL_FLOAT, data);
Alors qu'en OpenGL ES il faudra écrire:
Code:

1 2 3 4 glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_FLOAT, data); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_HALF_FLOAT_OES, data); glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, width, height, 0, GL_ALPHA, GL_FLOAT, data); glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, width, height, 0, GL_ALPHA, GL_HALF_FLOAT_OES, data);
Ceci dit en utilisant les defines du header de compatibilité que j'ai créé ci-dessus, il y a moyen d'avoir strictement la même écriture dans les 2 cas.
Mon seul regret est la disparition des Pixel Buffer Object (qui ne sont réintroduits que dans OpenGL ES 3), bien pratiques pour faire des transferts rapide de textures, j'ai du compenser en renvoyant mon architecture globale.
Je n'ai pas encore tout à fait finit le portage OpenGL mais le code minimal fonctionnel est en place, il ne faut pas hésiter à s'inspirer des exemples opengl fournis dans le SDK (qui sont pour la plupart compatibles OpenGL/OpenGL ES).

Au final j'ai du passer 10% du temps sur le passage Qt 4.8->Qt 5, 20% sur MinGW->MSVC, et 70% sur OpenGL->OpenGL ES (restructuration complète oblige).
En espérant que ce retour puisse vous éclairer !

11/01/2013, 21h39
LittleWhite

Bonjour,

Il y a le code d'exemple aussi de la formation des Qt Dev Days 2012 : http://qt.developpez.com/evenement/2.../dd-opengl.zip (je ne sais pas si c'est le même que celui de la documentation).