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.mcintyre@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-...
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/