[Development] OpenGL in Qt 5.1 and onwards

[Sean Harmer]

On Wednesday 16 January 2013 08:12:37 Samuel Rødal wrote:
> On 01/15/2013 05:05 PM, Sean Harmer wrote:
> > On Tuesday 15 January 2013 16:37:38 Samuel Rødal wrote:
> >> On 01/15/2013 02:43 PM, Sean Harmer wrote:
> >>> Hi,
> >>> 
> >>> On Monday 07 January 2013 10:00:47 Sean Harmer wrote:
> >>>> 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.
> >>> 
> >>> New version of the corresponding patch against dev is at:
> >>> 
> >>> https://codereview.qt-project.org/#change,44783
> >>> 
> >>> I have the numbers for a size comparison now. For a release build of
> >>> QtGui
> >>> from the dev branch on 64-bit Linux I have:
> >>> 
> >>> -rwxr-xr-x 1 sean_harmer users 4084848 Jan 14 11:01 libQt5Gui.so.5.0.1
> >>> 
> >>> With all of the extension and OpenGL versions classes in this grows to
> >>> 
> >>> -rwxr-xr-x 1 sean_harmer users 4781168 Jan 14 15:42 libQt5Gui.so.5.0.1
> >>> 
> >>> A delta of 696,320 bytes.
> >>> 
> >>> Gunnar/Samuel, I guess it is up to you guys whether to allow this into
> >>> QtGui or not. There are some knobs we can tweak to reduce the size
> >>> somewhat though so this is an absolute upper limit:
> >>> 
> >>> 1) Don't bother including classes for legacy versions of OpenGL
> >>> (1.0-2.1).
> >>> This eliminates approximately one half of the inheritance hierarchy in
> >>> the
> >>> classes introduced for OpenGL versions. This should be fine to live with
> >>> as
> >>> QOpenGLFunctions already makes most common functions available. Also,
> >>> new
> >>> code should really not be using these legacy API's. So really these are
> >>> just there for completeness. Could leave them in the source but have
> >>> them
> >>> compiled out by default via a #ifdef.
> >> 
> >> Sounds good to me to not include anything pre-QOpenGLFunctions. Then
> >> again I'm still not sure it's all worth to have in QtGui. Maybe a
> >> QtOpenGLEnablers module would be better? If so there might be less harm
> >> to have the earlier versions too.
> > 
> > Well yes we could put these into an enablers library as part of Qt3D for
> > example. Hmm actually it would be better as a new small module so that
> > QtQuick can use them. This would mean no access from QOpenGLContext
> > though. I would also need to refactor the other patches to resolve needed
> > symbols themselves.> 
> >>> 2) Do not include all extension classes. We could identify the most
> >>> commonly used extensions (somehow) and only include those by default.
> >>> Again we could allow someone to opt-in to other extensions, either
> >>> globally or on a case-by- case basis using #ifdefs. Again this should be
> >>> feasible as many extensions are essentially deprecated by having been
> >>> merged into the core features of newer versions or have been superseded
> >>> by new core features.
> >> 
> >> Maybe it could just include the extensions that have at some point
> >> become standardized as part of some OpenGL version? So
> >> QOpenGLExtension_EXT_framebuffer_blit but not
> >> QOpenGLExtension_NV_bindless_texture for instance.
> > 
> > The problem with that is that it kind of defeats the point of the
> > extension
> > mechanism. QOpenGLExtension_NV_bindless_texture is actually a good one to
> > pick on as this is a feature that recent nVidia cards are capable of in
> > hardware but which is only available in OpenGL. Direct3D without an
> > extension mechanism can not provide access to this useful feature.
> > 
> > The ones I would prefer to exclude are the obsolete ones, not the ones on
> > their way into a possible future core feature. Determining which ones go
> > into the obsolete set may take a little effort.
> 
> I guess I see the value in Qt providing them, it just seems a bit
> strange to include vendor-specific extensions.

Applications may well take advantage of vendor-specific extensions to optimise 
rendering where possible on the latest/specific target hardware.

> For OpenGL ES for
> instance there are at least NV, QCOM, ARM, AMD, IMG, and other vendor
> prefixed extensions. I see now that you've included most of those
> already, apart from the ARM ones?

Hmmm, I just included all those listed in the Khronos registry that define new 
entry points. The ARM extensions don't seem to do so:

/*------------------------------------------------------------------------*
 * ARM extension functions
 *------------------------------------------------------------------------*/

/* GL_ARM_mali_program_binary */
#ifndef GL_ARM_mali_program_binary
#define GL_ARM_mali_program_binary 1
#endif

/* GL_ARM_mali_shader_binary */
#ifndef GL_ARM_mali_shader_binary
#define GL_ARM_mali_shader_binary 1
#endif

/* GL_ARM_rgba8 */
#ifndef GL_ARM_rgba8
#define GL_ARM_rgba8 1
#endif

c.f. GL_APPLE_framebuffer_multisample for e.g.

/* GL_APPLE_framebuffer_multisample */
#ifndef GL_APPLE_framebuffer_multisample
#define GL_APPLE_framebuffer_multisample 1
#ifdef GL_GLEXT_PROTOTYPES
GL_APICALL void GL_APIENTRY glRenderbufferStorageMultisampleAPPLE (GLenum, 
GLsizei, GLenum, GLsizei, GLsizei);
GL_APICALL void GL_APIENTRY glResolveMultisampleFramebufferAPPLE (void);
#endif /* GL_GLEXT_PROTOTYPES */
typedef void (GL_APIENTRYP PFNGLRENDERBUFFERSTORAGEMULTISAMPLEAPPLEPROC) 
(GLenum target, GLsizei samples, GLenum internalformat, GLsizei width, GLsizei 
height);
typedef void (GL_APIENTRYP PFNGLRESOLVEMULTISAMPLEFRAMEBUFFERAPPLEPROC) 
(void);
#endif

> 3DFX extensions might be a bit
> obsolete these days though, who's going to write new code using those? :)

Indeed, those would be prime candidates for not being in the default set.

> Maybe a separate header for each vendor would make sense to not have
> such a huge header file.

That is certainly possible, likewise for EXT and ARB categories.

Cheers,

Sean