[Development] OpenGL in Qt 5.1 and onwards

[Samuel Rødal]

On 01/16/2013 09:58 AM, Sean Harmer wrote:
> 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

Ah, makes sense :)

>> 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.

Sounds good.

Now, about the library size issue. If we do establish a QtOpenGLEnablers 
module or similar, the question is whether scene graph will want to use 
it or not... If it does, then QtQuick will pull in all of the extensions 
again and we still have the size issue for a large portion of application.

Here's an idea: Since the extension headers include a large number of 
extensions and any one application will only use a small subset, maybe 
it would make sense to have the extensions in QtOpenGLExtensions, and 
have it be a statically linked library. Then only the subset of symbols 
that are actually used will get linked in.

Although if the library size requirements for the extensions is already 
quite small relative to QtGui or QtQuick it might not be an issue after all.

--
Samuel