[Development] The Dynamic OpenGL on Windows Change

[Simon Hausmann]

On Thursday 27. February 2014 14.33.56 Robert Knight wrote:
> > On Windows some older hardware and driver combinations
> > do not provide a sufficiently well working OpenGL implementation yet they
> > do have a working DirectX implementation which ANGLE then wraps to
> > provide an OpenGL ES 2 implementation
> 
> Do you have any idea of numbers or how old "old" is? What about Chrome
> / Mozilla's experiences
> with WebGL for example? I believe Chrome did or were using ANGLE for
> WebGL on Windows?

For a small taste of what Mozilla is going through, take a look at

    https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers

AFAICS this is for enabling GPU usage through DX, GL or disable altogether. So 
there's stuff like this:

    "All vendors other than AMD/ATI, NVIDIA, Intel are blocked"

    "We block the OpenGL drivers on AMD cards on Windows" (ANGLE is used 
instead)

    "We block the OpenGL drivers on Intel cards on Windows" (ANGLE is used 
instead - but also with a huge white list)

We really don't know ahead of time if ANGLE is usable or if we can fall back 
to OpenGL. It appears that at least Mozilla on Windows only uses OpenGL if the 
drivers are from Nvidia.



Simon
 
> On 27 February 2014 14:28, Sean Harmer <sean.harmer at kdab.com> wrote:
> > Hi everybody,
> > 
> > I would like to raise some concerns around the change that introduced
> > the dynamic selection of OpenGL on windows. For reference the change is
> > at:
> > 
> > https://codereview.qt-project.org/#change,76732
> > 
> > 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
> > Quick 2 depends upon having an OpenGL implementation to perform its
> > rendering. On Windows some older hardware and driver combinations do not
> > provide a sufficiently well working OpenGL implementation yet they do
> > have a working DirectX implementation which ANGLE then wraps to provide
> > an OpenGL ES 2 implementation.
> > 
> > That's all fine, some people need ANGLE to be able to use Qt Quick 2
> > others can use the desktop OpenGL build. So we offer two build
> > configurations of the SDK (multiplied by the other build options e.g. 32
> > vs 64-bit, MSVC vs mingw etc).
> > 
> > What I do not like about this change is that it adds a lot of
> > complexity, leading to more maintenance; it makes the runtime
> > performance worse for desktop and ES2 code paths if using the dynamic GL
> > build option; the user still has to care about ES2 vs desktop OpenGL
> > differences as the dynamic option pulls in the desktop GL header; it
> > exports all of the WGL, EGL and a whole bunch of OpenGL functions from
> > QtGui.dll. Incidentally what was the criteria used to decide which
> > OpenGL functions to export? I see there are a bunch of the old fixed
> > function pipeline functions exported which are of no use in ES 2 and
> > should not really be used in new GL code on the desktop either.
> > 
> > Let's think about that last one. Consider a situation where a customer
> > is writing an application that uses a 3rd party renderer of some sort
> > e.g. VTK, OpenSceneGraph or a map renderer. Their application links to
> > this library which in turn links to opengl32.dll and also to QtGui.dll.
> > Now we have a problem as both opengl32.dll and QtGui.dll both export the
> > GL functions.
> > 
> > So in this case the user has no option but to opt for the non-dynamic,
> > desktop OpenGL build of Qt anyway. Exporting the GL symbols from QtGui
> > for the lifetime of the 5.x series seems unwise, especially if the
> > intention is to remove the non-dynamic builds.
> > 
> > In summary I do not think this change is worth the costs associated with
> > it. Users that require the ANGLE build should use the ANGLE build. This
> > set should decrease in size as the older hardware/driver combos
> > naturally get refreshed.
> > 
> > Users that are doing anything with desktop OpenGL should use a desktop
> > OpenGL build to avoid the above symbol conflicts and the runtime costs.
> > 
> > This change seems to muddy the waters much more than it helps our end
> > users.
> > 
> > Kind regards,
> > 
> > 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