Hi Gunnar, On Monday 07 January 2013 08:28:35 Sletta Gunnar wrote: > On Dec 18, 2012, at 2:34 PM, Sean Harmer <sean.har...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
