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 <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
