Just some background FYI: when I worked for Graphics Working Group, I initiated the 'glproxy' project [1] for runtime detection of OpenGL/ES backends, and the development paused in mid 2012 for missing enough interest from the members.
[1] https://code.launchpad.net/glproxy On Tue, 27 Nov 2018 at 03:27, Adhemerval Zanella < adhemerval.zane...@linaro.org> wrote: > > > On 26/11/2018 16:58, Wookey wrote: > > On 2018-11-26 09:08 -0600, Tom Gall wrote: > >> On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre > >> <steve.mcint...@linaro.org> wrote: > >>> > >>> Quite. This is exactly the tension behind the dicussion - while arm64 > >>> machines are mainly mobile so far, we're finally starting to see > >>> bigger and more capable systems that you'd actually be happy to use as > >>> a desktop/laptop. > >>> > >>> Hence Wookey's question - is it possible to have a single sensible > >>> answer for both the (large) mobile hardware user base and the > >>> (smaller, but growing) bigger system users? We've seen conflicting > >>> information in that thread, hence asking here! :-) > >> > >> That is Vulkan. There is no mobile&embedded vs desktop fracture > >> like there is with GLES vs GL. In the design of the Vulkan standard > >> that was one mistake they were trying to address. > > > > That helps defuse this issue in the future, but it doesn't help for the > > debian/QT debate SFAICS. There are real applications, using openGL > > API, building against QT. Those apps are not going to be rewritten for > > the (completely different?) vulkan API quickly if at all. So QT > > GL/GLES support will exist and be used for a long time. > > > > Perhaps Vulkan can go in as an intermediate layer so that we don't > > have to care which flavour the graphics driver supports? I admit to > > negligible understanding of this stuff. > > To give more context, it seems that Qt already tries to have some runtime > support for OpenGL and OpenGL 3.x [1]. The possible option of OpenGL > support > on qt seems to be 1. -opengl es2 and 2. -opengl desktop and 3. -opengl > dynamic, > where 3. is the new dynamic one added on qt 5.6. > > Ubuntu indeed seems to be select the implementation based on the > architecture: > > --- > debian/rules: > > gles2_architectures := armel armhf arm64 > ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), > $(gles2_architectures))) > extra_configure_opts += -opengl es2 > else > extra_configure_opts += -opengl desktop > endif > --- > > So maybe one option is, if OpenGL 3.x support is mature enough, to check > if -opengl dynamic might be used. > > [1] > http://blog.qt.io/blog/2015/09/09/cross-platform-opengl-es-3-apps-with-qt-5-6/ > > > > >> I personally would aim for Vulkan. > > > > Which will happen for (some) new stuff presumably, although the > > switchover may be just as fast as X11->wayland (i.e. not very fast at > > all). > > > > How much work is conversion from openGL to Vulkan for an application? > > I don't have a good handle on how large the software base here is, but > > I think it's quite large - QT is popular and so is openGL. > > > > It is more work than adding GL support to the video drivers? (That is > > of course made much harder/(practically impossible?) by the total > > disaster that is proprietary video drivers on ARM (which Linaro has > > utterly failed to address in 8 years, except for Rob Clark)). > > > > I don't think 'use Vulkan' is a useful response to the question > > 'Should we build for GL or GLES on arm64?'. Or 'How can we make it > > possible to use GL on devices where only GLES is supported'. > > > > But perhaps I misunderstand. > > The problem with Qt/Vulkan support [1] is the Vulkan API is not abstracted > or hidden in any way and it does not cover cover modules like Qt Quick, > Qt 3D, Qt Canvas 3D, the OpenGL backend of QPainter, the GL > composition-based QOpenGLWidget/QQuickWidget, etc. It basically a no-go > as current support for Qt. > > [1] http://blog.qt.io/blog/2017/06/06/vulkan-support-qt-5-10-part-1/ > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
