[Development] OpenGL in Qt 5.1 and onwards

[Sean Harmer]

Hi Gunnar,

On Monday 07 January 2013 08:28:35 Sletta Gunnar wrote:
> On Dec 18, 2012, at 2:34 PM, Sean Harmer <sean.harmer at kdab.com> wrote:
> > 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:
> Hi Sean,
> 
> Late reply, but I think all in all this is great. 

No problem and Happy New Year!

> I would like to draw the
> line at 3D scene graph and model loaders and similar as I think this falls
> outside the scope of the module, but anything that makes OpenGL easier to
> use has my vote.
> > 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.
> 
> How much does this add to the library size when they are not used? One
> scenario for QtGui is to "give an OpenGL and an OpenGL context only". I'm
> thinking especially about embedded and low-end where library size might
> still matter. Could/should we put these behind an ifdef? Either
> !QT_OPENGL_ES or something else?

I'll get some numbers put together and report back shortly but the code 
already has a #ifdef QT_OPENGL_ES_2 to remove the desktop version-specific and 
extension classes.

> > 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.
> 
> Could you elaborate on this problem? I'm not familiar with it?

When I was preparing my devdays talk on rendering an OpenGL underlay with QQ2 
UI over the top I managed to get it working with a standard OpenGL 2.x context 
no problem.

When I wanted to do something more fancy with instanced rendering I needed an 
OpenGL 3.3 context. Trying this out I found that it works fine with a 
Compatibility profile context. However, using a Core profile context resulted 
in no QQ2 elements being drawn.

I suspect it's due to QQ2 using indexed draw calls but not using vertex array 
objects which are compulsory in the Core profile since the index buffer is 
contained in a VAO (whereas the VBOs are just referenced).

I need to find time to do a quick test to see if this is actually the case. 
The test could just be creating a single VAO and binding it up front when the 
SG context is initialized. That way all index buffer changes affect this 
default VAO.

> Qt Quick 2 will continue to use the golden subset of OpenGL 1/2/3/4 and
> OpenGL ES 2.0 that it currently uses for the foreseeable future, but then
> again, there is very little actual OpenGL in the public API. It would of
> course be possible to write a special renderer making use of certain
> desktop OpenGL features if these add significantly to the performance.

Yeah - we just need more hours in the day ;)

> > 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.
> 
> yep, these all sounds great.

I now have WIP patches for Geometry, Tessellation Control, Tessellation
Evaluation shader support. I'll work on the Compute shaders once I learn how 
to use them (only just got hold of capable drivers). Still needs some API 
clean-up and docs etc. 

I also have a WIP patch for OpenGL timer query objects (single and sets of 
them) and am now working on a higher-level abstraction for measuring rendering 
times and receiving the query results asynchronously one or more frames later. 
I need a good class name though, QOpenGLMultiFrameTimer?

I will push these to gerrit soon but they already work.

Occlusion queries or fence/sync objects will likely be next on my list.

> 
> > 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.
> 
> I think Lazlo has convinced me that a texture class in QtGui would make
> sense. We could then make use of it as input to textured geometry and wrap
> it in a QSGTexture.

OK. I will tidy up and complete my WIP texture (desktop and ES) and sampler 
(desktop only until we support ES 3) classes.

I will respond to your other email with my thoughts on where this lot should 
live.

Thanks for the feedback.

Sean