[Development] The Dynamic OpenGL on Windows Change

[Gunnar Sletta]

On 28 Feb 2014, at 13:16, Björn Breitmeyer <bjoern.breitmeyer at kdab.com> wrote:

> Since i haven't followed the discussion in detail, based on which assumptions 
> do you plan to use a dynamic switch. Exported GL Symbols from QtGui sounds
> like a very bad idea. Relying on QOpenGLFunctions makes more sense.

Agreed.

> 
> But right now i don't really see how this buys anybody anything, you usually 
> need to know which renderer to use, usually there is a switch in software if 
> they have different rederers so the user can change them if they don't work
> as expected. I have never really seen any runtime detection that works really
> well.

It is important to separate "Qt applications which actively use OpenGL" from those that "use OpenGL internally". 

For category 1, they should use desktop GL and nothing else. Ever. They will use raw GL calls and link directly to whatever GL library is on their platform. This should not change and should work as it always has without any changes to the application, save for maybe setting the Qt::AA_UseDesktopOpenGL flag (which could be set by default when Qt is configured with -opengl desktop)

For category 2, we want to remove as much pain as possible, so our users' users don't end up in a situation where they need to deal with GL drivers and hardware. This means moving QtQuick over to relying solely on QOpenGLFunctions and having a system in place where Qt can switch to ANGLE based and an ultimate fallback to software GL if we encounter something really bizarre. 

cheers,
Gunnar

> 
> Best regards
> Björn Breitmeyer
> 
> -- 
> Björn Breitmeyer | bjoern.breitmeyer at kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions 
> Am Freitag, 28. Februar 2014, 11:49:56 schrieb Agocs Laszlo:
>> You cannot include multiple GL headers. In a dynamic build you have the
>> desktop GL header ( + qopenglext.h), just like in a 'desktop' build. This
>> does not change at all.
> 
>> Runtime errors are not a problem since all ES-specific paths are guarded by
>> the appropriate condition.
> 
>> I realize however that there are genuine concerns around exporting all the
>> symbols from QtGui, and that the approach will most likely not scale to
>> other platforms. A compromise could be to revert the change for 5.3 (since
>> it is anyway behind an experimental configuration option) and instead try
>> gradually introducing an alternative approach in future releases:

sounds good.

> 
>> 1. Leave code that directly calls OpenGL functions alone. Instead, extend
>> QOpenGLFunctions with the common subset of OpenGL 1.x and ES2 functions
>> which are missing today. This would allow writing
>> context->functions()->glClear() etc. which is not possible today.

sounds good.

> 
>> 2. Once this is in place, all of qtbase and qtdeclarative (and later all
>> other modules) have to be changed to stop directly calling OpenGL
>> functions. Instead, they must rely on QOpenGLFunctions (which they most
>> likely do already for GL 2 specific calls anyhow). 

At least in those modules where it makes sense :)

> 
>> 3. QOpenGLFunctions gets platform specific backends that perform dynamic
>> loading of the OpenGL implementation. For example, the Windows backend
>> would do the tests for choosing between desktop - Angle and then
>> dynamically load the selected implementation. QtGui stops linking to
>> opengl32/libegl/libglesv2.

Sounds good, as long as the application can force the native "proper" GL library.

> 
>> 4. The windowing system interfacing code, for example all the usage of WGL
>> and EGL in the windows platform plugin, has to be placed behind a new
>> private wrapper similar to QOpenGLFunctions. This could expose an EGL-style
>> API, with platform specific backends  that provide an implementation using
>> the dynamically resolved EGL/WGL/GLX functions.



> 
>> Another alternative would be to continue betting on Angle as the primary
>> OpenGL enabler on Windows, and investigate how well the software rasterizer
>> fallback in D3D11-based Angle works. As I understand this would be
>> available on Win7+ in VS2012+ builds. If this could solve the issues we see
>> today with virtual machines and machines without decent drivers, it might
>> reduce the urgency for needing a true dynamic GL solution. 

We need it properly. If the user asks Desktop GL, he should get it. If the user doesn't know or care, Qt can make a best effort choice. ANGLE, ANGLE-software/DX or llvmpipe. The latter can be the default, but must not exclude the former.

> 
>> Cheers,
>> Laszlo
>> 
>> -----Original Message-----
>> From: Sean Harmer [mailto:sean.harmer at kdab.com] 
>> Sent: 28. februar 2014 11:41
>> To: development at qt-project.org
>> Cc: Gunnar Sletta; Agocs Laszlo
>> Subject: Re: Re: [Development] The Dynamic OpenGL on Windows Change
>> 
>> Hi Gunnar,
>> 
>> On Friday 28 February 2014 07:14:24 Gunnar Sletta wrote:
>> 
>>> On 27 Feb 2014, at 22:17, Agocs Laszlo <Laszlo.Agocs at digia.com> wrote:
>>> 
>>>> On Thu, Feb 27, 2014 at 02:28:26PM +0000, Sean Harmer wrote:
>>>> 
>>>>> The apparent problem that this is attempting to address is the need
>>>>> for
>>>>> both ANGLE and desktop OpenGL builds of Qt on windows. As you know Qt
>>>> 
>>>> 
>>>> As pointed out by Friedmann earlier, the big picture is a somewhat more
>>>> complicated. This is just the beginning.
>>> 
>>> ...
>>> 
>>> And I agree to all this. It is a good change, and I'm happy to see it.
>>> 
>>> Also, I would be very surprised if the added if-statements inside Qt
>>> makes
>>> much of a difference to performance. As long as that logic stays
>>> primarily
>>> inside Qt, it also doesn't hurt application complexity.
>> 
>> 
>> What I don't understand, and which is quite likely entirely my fault as I'm
>> 
> rather sleep-deprived recently (new baby), is that to me it seems like
>> situations such as trying to use desktop GL with an ES 2 build or vice
>> versa would have until now resulted in compile time errors. Now they will
>> become potential runtime errors (e.g. GL_INVALID_ENUM). Also, is it safe in
>> #include the ES2 headers on top of the desktop ones now and in the future?
>> That's a genuine question, I honestly don't know.
>> 
>> If everybody else is happy to live with this then I'll shut up. We should 
>> still consider if it makes sense for QtGui to export these symbols or
>> whether 
> they should be moved to a new library though.
>> 
>> Cheers,
>> 
>> Sean
>> --
>> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - Qt Experts - Platform-independent software solutions
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development