[Solved] Qt5 OpenGL reports wrong glVersion
-
I am facing this issue with the latest Qt code (gitorious). I have following environment.
Qt build on windows 7 using vs2010:
configure -developer-build -opensource -nomake examples -nomake tests -mp -opengl desktopI can see OpenGL 4.3 (Quadro K1000M/PCIe/SSE2 with 333 ext.) when i run Gpucaps. But when i run Qt applications and try to get GL_VERSION it returns 2.1.2
Any idea?
-
ZapB thanks for reply.
I am running this below sample app
http://qt-project.org/doc/qt-5.0/qtquick/scenegraph-openglunderqml.htmlAnd inside "Squircle::paint()":http://qt-project.org/doc/qt-5.0/qtquick/scenegraph-openglunderqml-squircle-cpp.html function i am trying to get opengl verison like below
@char *ver = (char *) glGetString(GL_VERSION);@
And it returns opengl version 2.1.2.
As a workaround i am doing following, this fixes the issue somewhat. But problem is that when i set version more than 3.1 i get a black blank screen.
@ QQuickView view;
QSurfaceFormat format;
format.setProfile(QSurfaceFormat::CoreProfile);
format.setVersion(3, 1);
view.setFormat(format);
@But i don't want to hard code any opengl version. Why Qt is not returning a correct opengl version? Other interesting thing which i noticed when i was debugging, inside the Qt in below code during initialization it returns correct version 4.3.0; but somehow it never gets reflected.
@QWindowsOpenGLContextFormat QWindowsOpenGLContextFormat::current()
{
QWindowsOpenGLContextFormat result;
const QByteArray version = QOpenGLStaticContext::getGlString(GL_VERSION);
.
.
.
}
@ -
Hi,
I'm trying to use the new Qt / openGL design. Every time I get a success, I realize there is something wrong once again.
First I would like to point out that the sample here doesn't work (Win7 VS2010):
"OpenGL Window Example":http://qt-project.org/doc/qt-5/qtgui-openglwindow-example.html
It gives me a black screen and that's it. But no worries, many samples out there seems to be from 5.0, 5.1 or an unknown version in between and none actually works on 5.2. Didn't try on 5.1, 5.0 nor 5.3 Beta.
And I did install this version of Qt :
"Qt5.2 VS2010 OpenGL":Qt 5.2.1 for Windows 32-bit (VS 2010, OpenGL, 517 MB)
So I don't know if this bug applies to me :
"Windows builds should ship a standard Open GL build":https://bugreports.qt-project.org/browse/QTBUG-28715The trick I found was to remove the QOpenGLFunctions from the inheritance of OpenGLWindow and used a QOpenGLFunctions_4_3_Core instead as an attribute of the class.
Then instead of calling "initializeOpenGLFunctions();", I get the functions from the newly created context with versionFunctions() and then initialize this set of functions.After this step, I finally got a visual. The magical triangle that is, even ten years later, still a long and painful process to obtain when changing API.
Anyway, after that I though I was finally free to do whatever. But no.
In the code I was barbarically casting the return of "m_context->versionFunctions();" to "QOpenGLFunctions_4_3_Core*". But when I try to be more gentle and dynamic cast it to the proper class, I get a NULL. When debugging I noticed that the original class was in fact a QOpenGLFunctions_2_1.So I came back to the source. I realized that my surface format was by default set for 2.1. So I changed that to 4.3 before calling show(). Then I checked and :
My surface format is 4.3, horayyy
My context format is 4.3 horayyyyy
The dynamic cast works horaayyyy!!
But the window is black.So what ? please what ?
-
First of all, yes, QSurfaceFormat defaults to requesting a 2.x context as this is the minimum required for Qt Quick 2. If you want an OpenGL 4.3 context you need to ask for it via QSurfaceFormat::setVersion() as you found.
Second, there is no need to cast the result form QOpenGLContext::versionFunctions() if you use the templated version of it. e.g.
@
m_funcs = context->versionFunctions<QOpenGLFunctions_4_3_Core>();
if (!m_funcs)
// something went wrong. fallback or bail out
@As to why you see nothing when using OpenGL 4.3 I suspect that is because that example is written against older style OpenGL as evidenced by the fact it worked with OpenGL 2.x profile. To test this you could ask for an OpenGL 4.3 Compatibility profile context so that the stuff which is deprecated and removed in the core profile is still available. See QSurfaceFormat::setProfile().
Alternatively you would need to port the rest of the example to use only Core profile features. That is remove all of the fixed function pipeline calls and built in shader uniforms. Also you would need to tweak the shaders to use in/out rather than attribute/varying.
Good luck.
-
Ohhhh god I love you.
Compatibility profile worked. However, opengl.org is down from my side. I can't check what's supported in 3.1 core and what has been thrown away.
On the shaders, I clearly specify the version 420, so if it compile, am I good to assume there is no problem there ? I use gl_Position still, but I don't recall having an alternative.
On the code, the only functions used with QOpenGLFunctions are :
glClear(), glViewport(), glDrawArrays().
The other calls are made from the program itself :
link(), bind(), enableAttributeArray(), setAttributeBuffer(), disableAttributeArray(), release().
And finally, I use QOpenGLBuffers for my meshes info :
create(), setUsagePattern(), bind(), allocate().That's it. I know glViewport and glDrawArrays are not deprecated. Is glClear my issue ?
Also, the context does a swapBuffers(), is it ok ? -
I check the glError after each call and an error pops up for each call to QOpenGLShaderProgram::setAttributeBuffer :
"m_program->setAttributeBuffer("posAttr", GL_FLOAT, 0, 2);"
"m_program->setAttributeBuffer("colAttr", GL_FLOAT, 0, 3);"
This error doesn't show up for compatibility profile. Safe to assume this is my culprit ?
Any idea ? -
The problems will be in the shaders themselves.
The vertex shader has code like this for the input vertex attribute variables:
@
attribute vec2 posAttr;
attribute vec3 colAttr;
@The attribute keyword is gone in the Core profile. Instead yuo have to use "in":
@
in vec2 posAttr;
in vec3 colAttr;
@And in the vertex shader instead of using "varying" for the output you use "out". You still need to write to gl_Position as the input to the rasterizer though.
Then in the fragment shader for the input variables you no longer use "varying" but rather "in".
For the fragment shader output the old built-in variable gl_FragColor is gone. Instead you must define your own output variable for the fragment shader and write to that. Something like this...
@
out vec4 fragColor;
...
void main()
{
...
fragColor = vec4(...);
}
@Hope this helps.
-
My shaders are arleady set to version 420
@#version 420
in vec2 posAttr;
in vec3 colAttr;uniform mat4 matrix;
out vec4 vCol;
void main() {
vCol = vec4(colAttr, 1.0);
gl_Position = matrix * vec4(posAttr, 0.0, 1.0);
}@@#version 420
in vec4 vCol;
out vec4 fCol;
void main() {
fCol = vCol;
}@Is there an issue ?
-
You tell me ;) Do they compile and link? Can you obtain the locations of the attributes?
Are you creating and binidng a vertex array object anywhere? Core profile requires that you bind a vertex array object. This can be as simple as creating a QOpenGLVertexArrayObject instance and in your init function doing:
@
m_vao.create();
m_vao.bind();
@Of course that is the minimal way to do it. You can have multiple VAOs in a program.
-
Direct hit :D.
My shaders were compiling, no problem on this side (otherwise I wouldn't be able to see anything with the 2.1 profile anyway).
The problem was the VAO. As soon as I created/binded one in my init then bind it the rendering, "pouf" it worked.Thanks for the help. That was some kick ass troubleshooting you've done here :D.
Cheers.
PS : Maybe update the sample in the Qt Wiki. I don't think there is any example that works for 5.2 out there.
-
Great! Glad you got it working.
I plan to add some examples to Qt for 5.4 showing some of the newer OpenGL features and the helpers in Qt.
BTW, in case you or anybody else is interested, KDAB offers training courses in "Modern OpenGL and Qt":http://www.kdab.com/training/courses/modern-opengl-with-qt/
Happy hacking!
-
And if I may, the courses are worth both the time and money !
