[Development] OpenGL in Qt 5.1 and onwards

Sean Harmer sean.harmer at kdab.com
Tue Dec 18 14:34:32 CET 2012


Hi,

I would like to start a discussion on the future level of support for OpenGL 
enablers in Qt for those that are interested. So here goes...

I would like to add in a bunch more OpenGL enablers but am not sure on where 
to best put them. Some things I have in mind are:

1) Classes that contain member functions for all OpenGL functions of a given 
version and profile. E.g. no need to use GLEW or similar. WIP version of this 
at 

https://codereview.qt-project.org/#change,35408

This needs resubmitting against dev of course which I will do after some 
refactoring of the underlying code-generator and trying an experiment with a 
different inheritance hierarchy.

Where should this live? It fits in nicely with obtaining pointers to such 
objects directly from QOpenGLContext. However, it does add size to QtGui so 
some people may object to this being located there. The vast majority of 
functions are inline. The other option is to put it into a Qt3D OpenGL-enabler 
library and create the objects via some factory class.

At present I have a bunch of other WIP patches based upon this work but they 
could be refactored to resolve the necessary GL functions themselves. Using 
these classes would make the others easier to implement but not impossible 
without.

2) An QOpenGLVertexArrayObject class. This would be just a thin wrapper around 
a VAO with possibly some API to make it easier to use with QOpenGLBuffer and 
QOpenGLShaderProgram. 

This could potentially find use in QtQuick 2 so putting it in QtGui alongside 
the other QOpenGL* classes makes sense. I think the lack of VAO's in 
qtdeclarative is what makes it necessary to still use a compatibility profile 
with QtQuick 2. This limits the GL features we can use in conjunction with QQ2 
on Mac as Apple only implement the Core Profile for GL 3.x. That is another 
story though.

3) OpenGL occlusion and timing query objects. Again these are good candidates 
for QtGui I think but if people object they could go into Qt3D again. The 
timing query object in particular would be valuable for profiling the GPU time 
spent in rendering QtQuick 2 scenes. Iirc then right now only the CPU time is 
available in qtdeclarative but that is only half the story for profiling this 
stuff.

4) Transform feedback object. Another small but useful candidate for inclusion 
in QtGui. These objects allow you to perform calculations on the GPU and write 
the results to a bound buffer object before the rasterisation stage. This can 
be used to perform animation updates for particles or physical simulations on 
the GPU for example. The output buffer is then used in a second pass to render 
with the calculated parameters. Would be very nice to integrate with 
QOpenGLBuffer and QOpenGLShaderProgram again.

5) Provide support for Geometry, Tessellation Control, Tessellation Evaluation 
and Compute Shader support in QOpenGLShaderProgram. I don't see anything 
contentious with these. They are just extending QOpenGLShader and/or 
QOpenGLShaderProgram.

6) Integrate support for the GL_ARB_debug_output extension into the Qt debug 
message system. Peppe has said he will start to look at this shortly and I 
think this would be an awesome feature to have available where the extension 
is supported.

7) More enabler classes for textures, samplers, and higher-level abstractions. 
I think these would be good candidates for a Qt3D library, unless someone 
would really like to see a subset in QtGui.

Any feedback welcomed.

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


More information about the Development mailing list