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.ag...@digia.com wrote: On Thu, Feb 27, 2014 at 02:28:26PM +, 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.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
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: 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. 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). 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. 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. Cheers, Laszlo -Original Message- From: Sean Harmer [mailto:sean.har...@kdab.com] Sent: 28. februar 2014 11:41 To: development@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.ag...@digia.com wrote: On Thu, Feb 27, 2014 at 02:28:26PM +, 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.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
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. 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. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo 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: 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. 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). 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. 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. Cheers, Laszlo -Original Message- From: Sean Harmer [mailto:sean.har...@kdab.com] Sent: 28. februar 2014 11:41 To: development@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.ag...@digia.com wrote: On Thu, Feb 27, 2014 at 02:28:26PM +, 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.har...@kdab.com | Managing
Re: [Development] The Dynamic OpenGL on Windows Change
Keep in mind, though, that the primary goal of QtGui is to enable Qt Quick and related modules, like Controls, which are all based on OpenGL [ES] 2.0. Supporting 3rd party renderers that explicitly rely on GL3+ features and are not interested in true portability (e.g. between desktop and mobile) is not QtGui's job and is not in scope here, obviously, since some of the implementations we would dynamically select do only ES 2 or GL 2.1. Best regards, Laszlo -Original Message- From: Björn Breitmeyer [mailto:bjoern.breitme...@kdab.com] Sent: 28. februar 2014 13:16 To: development@qt-project.org Cc: Agocs Laszlo; Sean Harmer Subject: Re: [Development] The Dynamic OpenGL on Windows Change 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. 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. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo 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: 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. 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). 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. 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. Cheers, Laszlo -Original Message- From: Sean Harmer [mailto:sean.har...@kdab.com] Sent: 28. februar 2014 11:41 To: development@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.ag...@digia.com wrote: On Thu, Feb 27, 2014 at 02:28:26PM +, 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
Re: [Development] The Dynamic OpenGL on Windows Change
On 28 Feb 2014, at 13:16, Björn Breitmeyer bjoern.breitme...@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.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo 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.har...@kdab.com] Sent: 28. februar 2014 11:41 To: development@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.ag...@digia.com wrote: On Thu, Feb 27
Re: [Development] The Dynamic OpenGL on Windows Change
Hi Sean, It is most likely better to postpone this whole feature, especially since it is not really user visible anyhow, and instead try mitigating the pain using some less intrusive methods for the time being, agreed. I am currently preparing a revert commit. As for the role of qtbase and QtGui, I am afraid we will continue to disagree but perhaps that's fine. One cannot agree on everything. :) Best regards, Laszlo -Original Message- From: Sean Harmer [mailto:sean.har...@kdab.com] Sent: 28. februar 2014 14:07 To: Agocs Laszlo Cc: Björn Breitmeyer; development@qt-project.org Subject: Re: RE: [Development] The Dynamic OpenGL on Windows Change Hi Laszlo, On Friday 28 February 2014 12:25:19 Agocs Laszlo wrote: Keep in mind, though, that the primary goal of QtGui is to enable Qt Quick and related modules, like Controls, which are all based on OpenGL [ES] 2.0. Supporting 3rd party renderers that explicitly rely on GL3+ features and are not interested in true portability (e.g. between desktop and mobile) is not QtGui's job and is not in scope here, obviously, since some of the implementations we would dynamically select do only ES 2 or GL 2.1. This is where I disagree. The goal of QtGui is to enable developers to write GUI applications easily and efficiently. Those applications may or may not use Qt Quick 2 and/or controls and many of them of course do so. However, a very large percentage also need to integrate with other things too. I agree with Bjoern and Gunnar that making use of QOpenGLFunctions within Qt Quick 2 seems the better way to go. I still need to think my way through more of this yet and my brain is already suffering from the Friday Feeling. I totally understand the desire to be able to select an OpenGL/ES2 implementation at runtime for applications that are only using OpenGL indirectly via Qt Quick 2. Have a good weekend, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi Laszlo, On Friday 28 February 2014 13:27:40 Agocs Laszlo wrote: It is most likely better to postpone this whole feature, especially since it is not really user visible anyhow, and instead try mitigating the pain using some less intrusive methods for the time being, agreed. I am currently preparing a revert commit. Thank you. Sorry this means it gets reverted for now. I think we all agree that having the common ES2 / desktop 2 subset magically work everywhere on Windows is a good thing but that we need to be careful about how we do it. Peppe just came up with another option which would be to move the magic stuff into a new C-only, BSD licensed library that we could perhaps share with the likes of Mozilla to implement the decision making for desktop vs ES based upon theirs and ours combined experiences. As for the role of qtbase and QtGui, I am afraid we will continue to disagree but perhaps that's fine. One cannot agree on everything. :) Indeed. Life would be very boring then! For now we have to argue for what our customers are telling us which is that Qt Quick 2 is a very important piece of the puzzle but that it is by no means the only piece. Have a good weekend, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi Laszlo, On Friday 28 February 2014 12:25:19 Agocs Laszlo wrote: Keep in mind, though, that the primary goal of QtGui is to enable Qt Quick and related modules, like Controls, which are all based on OpenGL [ES] 2.0. Supporting 3rd party renderers that explicitly rely on GL3+ features and are not interested in true portability (e.g. between desktop and mobile) is not QtGui's job and is not in scope here, obviously, since some of the implementations we would dynamically select do only ES 2 or GL 2.1. This is where I disagree. The goal of QtGui is to enable developers to write GUI applications easily and efficiently. Those applications may or may not use Qt Quick 2 and/or controls and many of them of course do so. However, a very large percentage also need to integrate with other things too. I agree with Bjoern and Gunnar that making use of QOpenGLFunctions within Qt Quick 2 seems the better way to go. I still need to think my way through more of this yet and my brain is already suffering from the Friday Feeling. I totally understand the desire to be able to select an OpenGL/ES2 implementation at runtime for applications that are only using OpenGL indirectly via Qt Quick 2. Have a good weekend, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi, Thank you. Sorry this means it gets reverted for now. I think we all agree that having the common ES2 / desktop 2 subset magically work everywhere on Windows Ok, technically speaking, how do we get this through the CI (considering the modules which have follow-up changes ..can we leave the functionality providing the isES() function in place? Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
On Friday 28 February 2014 14:53:02 Friedemann Kleint wrote: Hi, Thank you. Sorry this means it gets reverted for now. I think we all agree that having the common ES2 / desktop 2 subset magically work everywhere on Windows Ok, technically speaking, how do we get this through the CI (considering the modules which have follow-up changes ..can we leave the functionality providing the isES() function in place? Sure, I think that's fine to leave in place. Only query I have around that is if it would make more sense being on the QOpenGLContext rather than QOpenGLFunctions. Thoughts? Cheers, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi Andre, On Thursday 27 February 2014 20:36:51 andre wrote: On Thu, Feb 27, 2014 at 02:28:26PM +, Sean Harmer wrote: You miss the point that Qt users are typically developers themselves, who have not just their own development machine to take care of (plus their corporate IT...) but an application they wish to make as widely and as easily available as possible. Offering a real end user a choice Do you wish to install our application on a machine that has good OpenGL support, or would you prefer to download an ANGLE based version? is a no-go. Not addressing the problem on the Qt side just shifts the burden to the developer-users, multiplying the work needed by a factor in the order of developer-users with real end-users. Not at all. I want our developers to have the best experience possible. I just don't want it to come at the cost of other developers who need to do more than only use Qt Quick 2. Anyway it seems we've reached a consensus in the other parts of this thread about a way forwards. You could have argued that given the general state of OpenGL support in the wild it is a questionable choice as painting abstraction layer, and some people might have agreed, but consolidating the number of physical builds helps at least at the user visible layer. (user in the widest sense: Release team, developer-users, end users) I agree that using OpenGL across the board on windows is perhaps not the best choice at this time due to the highly variable driver quality and availability. It may be that for Qt6 we should consider providing an abstraction at a different level to allow for a genuine Direct3D renderer for Qt Quick in a similar way that the likes of OGRE offer the choice. However, that is a far bigger change. Another option would be to have provide assistance in providing a software fallback in the form of mesa + llvmpipe or similar. Have a good weekend, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Yes, it should be pretty simple: Just remove qopenglproxy_win.cpp and leave everything else in place. This provides an excellent foundation for continuing the feature with a different approach. The other modules are not an issue since the related changes have not been merged (with the exception of one very small change). At the same time this gives us an opportunity to revive https://codereview.qt-project.org/#change,79271 by moving isES() to QOpenGLContext and separating the two conceptually different queries (is this context ES / is my OpenGL implementation ES only) into two different functions. Cheers, Laszlo -Original Message- From: development-bounces+laszlo.agocs=digia@qt-project.org [mailto:development-bounces+laszlo.agocs=digia@qt-project.org] On Behalf Of Sean Harmer Sent: 28. februar 2014 15:39 To: development@qt-project.org Subject: Re: [Development] The Dynamic OpenGL on Windows Change On Friday 28 February 2014 14:53:02 Friedemann Kleint wrote: Hi, Thank you. Sorry this means it gets reverted for now. I think we all agree that having the common ES2 / desktop 2 subset magically work everywhere on Windows Ok, technically speaking, how do we get this through the CI (considering the modules which have follow-up changes ..can we leave the functionality providing the isES() function in place? Sure, I think that's fine to leave in place. Only query I have around that is if it would make more sense being on the QOpenGLContext rather than QOpenGLFunctions. Thoughts? Cheers, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Em sex 28 fev 2014, às 11:49:56, Agocs Laszlo escreveu: 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. Please make sure they are properly namespaced: all symbols exported from our libraries should start with Q or q. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Il 28/02/2014 17:21, Thiago Macieira ha scritto: Please make sure they are properly namespaced: all symbols exported from our libraries should start with Q or q. Not really, these symbols are the GL1 + GLES2 + EGL subset (so that apps using glFoo* will find them in QtGui). See https://codereview.qt-project.org/#patch,sidebyside,76732,30,src/gui/opengl/qopenglproxy_win.cpp around line 1500. That's (also) a good argument for moving the contents of that file in a separate, BSD licensed (so that its valuable for Mozilla / Chromium / other people fighting against Windows), pure C library, and then having QtGui link against that other library. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
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? On 27 February 2014 14:28, Sean Harmer sean.har...@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.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
On 27/02/2014 14:33, 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? We don't have any firm numbers which is why Gunnar was asking for feedback on this a couple of months ago. What we do know is that the Intel OpenGL drivers have massively improved in the last 12 months and now are quite capable of rendering what Qt Quick 2 sends down the pipeline. Of course some people are unable to upgrade to these versions due to uncooperative corporate IT departments or for other reasons such as certified combinations of system components etc. I'm not debating the need for an ANGLE build to support these and other valid cases. What I am debating is that having the dynamic selection between ES 2 and desktop OpenGL with the current implementation is worth the costs as outlined previously. Cheers, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
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.har...@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.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi, the intention was here to pave to way for a software renderer for platforms that have no GL at all (virtual machines, remote logins, etc, see https://bugreports.qt-project.org/browse/QTBUG-36091 ). The initial versions of https://codereview.qt-project.org/#change,76732 had a separate QOpenGLProxy module, but we decided to move it into Qt5Gui since otherwise the user would have to deploy yet another library. But having a separate module would not help in the scenario you described (3rd party renderer of some sort e.g. VTK, OpenSceneGraph...), either? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi Friedemann, On 27/02/2014 15:42, Friedemann Kleint wrote: Hi, the intention was here to pave to way for a software renderer for platforms that have no GL at all (virtual machines, remote logins, etc, see https://bugreports.qt-project.org/browse/QTBUG-36091 ). Is this not trying to solve the problem at the wrong level? This sounds like it would be better resolved as a system configuration/deployment approach by having those systems use mesa's llvmpipe opengl32.dll as the OpenGL implementation rather than trying to solve it from within Qt itself. The initial versions of https://codereview.qt-project.org/#change,76732 had a separate QOpenGLProxy module, but we decided to move it into Qt5Gui since otherwise the user would have to deploy yet another library. But having a separate module would not help in the scenario you described (3rd party renderer of some sort e.g. VTK, OpenSceneGraph...), either? How does this change help with that? Is it on the assumption that any software renderer would be limited to OpenGL ES 2? And I think yes we could still end up with a mess with conflicting symbols. Only the application developer knows what they need and what their other dependencies are. I'm not sure we can solve this particular problem within Qt or should even be trying to do so for fear of backing ourselves into a corner in the future. Maybe I'm missing something that everybody else sees though? Cheers, Sean -- Dr Sean Harmer | sean.har...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
On Thu, Feb 27, 2014 at 02:28:26PM +, Sean Harmer 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). [And that is a problem by itself.] 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 Real-world numbers, please. 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. You miss the point that Qt users are typically developers themselves, who have not just their own development machine to take care of (plus their corporate IT...) but an application they wish to make as widely and as easily available as possible. Offering a real end user a choice Do you wish to install our application on a machine that has good OpenGL support, or would you prefer to download an ANGLE based version? is a no-go. Not addressing the problem on the Qt side just shifts the burden to the developer-users, multiplying the work needed by a factor in the order of developer-users with real end-users. You could have argued that given the general state of OpenGL support in the wild it is a questionable choice as painting abstraction layer, and some people might have agreed, but consolidating the number of physical builds helps at least at the user visible layer. (user in the widest sense: Release team, developer-users, end users) This change seems to muddy the waters much more than it helps our end users. Quite the opposite in my opinion. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
On 27 Feb 2014, at 22:17, Agocs Laszlo laszlo.ag...@digia.com wrote: On Thu, Feb 27, 2014 at 02:28:26PM +, 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. 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 OpenGL 1.1 (i.e. whatever is in GL.h), WGL (the subset in wingdi.h), GLES 2.0 and EGL 1.4. This covers the functions available in opengl32.dll and Angle's libegl+libglesv2. Everything else is queried during runtime using the appropriate getProcAddress variant. Why these exports? Compatibility. Anything that directly calls glClear() today should continue to function. Instructions like migrate all your code to use a new fancy wrapper class are not feasible, not in Qt 5.x at least. (not that they are that desirable in Qt 6 either...) This is not how we talked about doing this before. Anything that calls glClear today is already linking against opengl32.dll and should continue to do so. In addition, they are required to in some way or form tell Qt to use desktop GL which is their preferred choice. For instance, setting the AA_UseDesktopOpenGL application flag to force Qt to use the right OpenGL libraries at runtime. 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. These applications are broken already today when using the default build of Qt that uses Angle. The point is that none of these applications used ANGLE. They used desktop GL and now they are potentially broken. I think we should set AA_UseDesktopOpenGL to true by default if Qt is configured with -opengl desktop. (Not saying Qt needs to be built with this option by default though). The overall goal of this change is that those that Qt takes care of OpenGL for those that do not care or do not know. Those that do care will almost always want proper desktop OpenGL on desktops and should not be hampered by it. cheers, Gunnar Which means the developer has to know, already today, that the 3rd party code requires opengl32 and so the application needs to use a matching Qt build. With dynamic GL, there is no issue. The 3rd party library links to opengl32.dll. The application links to QtGui which dynamically loads opengl32. This should work fine. As for statically linking in 3rd party code into the application, that can conflict, yes. This is unavoidable and cannot be skipped with any sort of dynamic OpenGL loading approach, no matter what we do. Best regards, Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
On Behalf Of Sean Harmer On 27/02/2014 15:42, Friedemann Kleint wrote: Hi, the intention was here to pave to way for a software renderer for platforms that have no GL at all (virtual machines, remote logins, etc, see https://bugreports.qt-project.org/browse/QTBUG-36091 ). Is this not trying to solve the problem at the wrong level? This sounds like it would be better resolved as a system configuration/deployment approach by having those systems use mesa's llvmpipe opengl32.dll as the OpenGL implementation rather than trying to solve it from within Qt itself. Yes - ideally, this should be resolved as a system deployment approach, but the corporation that controls the system (Microsoft) have little interest in deploying opengl drivers to the system. I therefore don't think this can be resolved as a system deployment approach, since ANGLE/llvmpipe is not part of the OS graphics stack on windows. When I install a new graphics card (or even just upgrade the graphics card driver), I expect that the software on the system will automatically take advantage of its new capabilities next time it is started. Jan Arve ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
