A long time ago in Linaro we looked at the issue of openGL vs OpenGLES on arm, including the possibility of a shim library to make it easier for applications to switch between them.
Who knows about this and what happened/was decided?
The Debian QT maintainers are currently considering switching from building QT for arm64 for openGLES instead of openGL because there is a lot more hardware available (cheapish dev boards) with drivers supporting GLES then desktop style hardware with standard graphics card supporting 'proper GL'. Ubuntu did this 2 years ago.
Unfortunately building for 'either' seems to be very difficult due to ABI incompatibilities.
In general we don't want gratuitous difference between arm64 and x86, so this seems problematic, but I am no expert in this area and would like to talk to someone who does know about this stuff, and perhaps this needs to go back on the Linaro roadmap for fixing?
Wookey
Hi Wookey,
This was something bouncing around in the Graphics Working Group back in the day. Alexandros as I recall was the key dev. As far as a shim goes given the effort that would have been involved and the lack of interest, it wasn't worked on.
For ARM64 and QT would a move to GLES be a "good thing?" Yes.
When it comes to graphics drivers today for arm hardware GLES is pretty universal. GLES is a standard, there is compliance through Khronos. There is a whole game industry built on top of GLES on Android devices so behavior differences between GLES implementations should in theory be the exception not the norm tho there are platform extensions that are found. (GL has the same concept)
Going forward the industry has been picking up Vulkan. Vulkan however is not universal. Vulkan has hardware requirements which for whole generations of graphics hardware (like Mali 4xx) are not able to support.
As Vulkan is becoming more central to Android's Graphics strategy, it probably would be wise for the QT types to keep an eye on that.
On Mon, Nov 26, 2018 at 7:51 AM Wookey wookey@wookware.org wrote:
A long time ago in Linaro we looked at the issue of openGL vs OpenGLES on arm, including the possibility of a shim library to make it easier for applications to switch between them.
Who knows about this and what happened/was decided?
The Debian QT maintainers are currently considering switching from building QT for arm64 for openGLES instead of openGL because there is a lot more hardware available (cheapish dev boards) with drivers supporting GLES then desktop style hardware with standard graphics card supporting 'proper GL'. Ubuntu did this 2 years ago.
Unfortunately building for 'either' seems to be very difficult due to ABI incompatibilities.
In general we don't want gratuitous difference between arm64 and x86, so this seems problematic, but I am no expert in this area and would like to talk to someone who does know about this stuff, and perhaps this needs to go back on the Linaro roadmap for fixing?
Wookey
Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, 26 Nov 2018 at 14:03, Tom Gall tom.gall@linaro.org wrote:
Hi Wookey,
This was something bouncing around in the Graphics Working Group back in the day. Alexandros as I recall was the key dev. As far as a shim goes given the effort that would have been involved and the lack of interest, it wasn't worked on.
For ARM64 and QT would a move to GLES be a "good thing?" Yes.
When it comes to graphics drivers today for arm hardware GLES is pretty universal. GLES is a standard, there is compliance through
*Shouts* ThunderX2 Workstation very loudly at this point, following by Linaro Developer Box, Macchiato bin.....
Linaro is more than Android!
Going forward the industry has been picking up Vulkan. Vulkan however is not universal. Vulkan has hardware requirements which for whole generations of graphics hardware (like Mali 4xx) are not able to support.
As Vulkan is becoming more central to Android's Graphics strategy, it probably would be wise for the QT types to keep an eye on that.
And yes Vulkan is the future if you are not DirectX and will work on the above machines quite fine too!
Graeme
On Mon, Nov 26, 2018 at 02:11:10PM +0000, Graeme Gregory wrote:
On Mon, 26 Nov 2018 at 14:03, Tom Gall tom.gall@linaro.org wrote:
Hi Wookey,
This was something bouncing around in the Graphics Working Group back in the day. Alexandros as I recall was the key dev. As far as a shim goes given the effort that would have been involved and the lack of interest, it wasn't worked on.
For ARM64 and QT would a move to GLES be a "good thing?" Yes.
When it comes to graphics drivers today for arm hardware GLES is pretty universal. GLES is a standard, there is compliance through
*Shouts* ThunderX2 Workstation very loudly at this point, following by Linaro Developer Box, Macchiato bin.....
Linaro is more than Android!
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! :-)
Is it true that most PCIe graphics cards (and drivers) will also support GLES as well as GL? I've seen that asserted.
Cheers,
On Mon, 26 Nov 2018 at 14:46, Steve McIntyre steve.mcintyre@linaro.org wrote:
Is it true that most PCIe graphics cards (and drivers) will also support GLES as well as GL? I've seen that asserted.
Supporting GLES doesn't mean applications will use GLES. Desktop applications use GL/DX (via Wine)/Vulkan. I'm no expert in GL/GLES, but I think they're quite different standards.
I can attest quite strongly that the DX-to-GL bridge done by Wine, while commendable, is not how we want to present ourselves in desktop environments. Vulkan is being pushed hard by some studios because it happens to consistently outperform DX on Windows and it's much easier to work with (sane standard). Valve is pushing Vulkan even harder, so that it can work on Linux, too.
Any GL-to-GLES (or vice-versa) work will be thrown away. Moving ARMv8 towards GLES is a huge mistake, IMHO, and one which history will not be too kind to. I can almost hear Linus saying something about video quality on Arm.
On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre steve.mcintyre@linaro.org wrote:
On Mon, Nov 26, 2018 at 02:11:10PM +0000, Graeme Gregory wrote:
On Mon, 26 Nov 2018 at 14:03, Tom Gall tom.gall@linaro.org wrote:
Hi Wookey,
This was something bouncing around in the Graphics Working Group back in the day. Alexandros as I recall was the key dev. As far as a shim goes given the effort that would have been involved and the lack of interest, it wasn't worked on.
For ARM64 and QT would a move to GLES be a "good thing?" Yes.
When it comes to graphics drivers today for arm hardware GLES is pretty universal. GLES is a standard, there is compliance through
*Shouts* ThunderX2 Workstation very loudly at this point, following by Linaro Developer Box, Macchiato bin.....
Linaro is more than Android!
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.
I personally would aim for Vulkan.
Is it true that most PCIe graphics cards (and drivers) will also support GLES as well as GL? I've seen that asserted.
As a litmus test, I don't see any GLES drivers on nVideas website. Both Vulkan and GL are there tho.
Cheers,
Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
On Mon, Nov 26, 2018 at 9:10 AM Tom Gall tom.gall@linaro.org wrote:
On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre steve.mcintyre@linaro.org wrote:
On Mon, Nov 26, 2018 at 02:11:10PM +0000, Graeme Gregory wrote:
On Mon, 26 Nov 2018 at 14:03, Tom Gall tom.gall@linaro.org wrote:
Hi Wookey,
This was something bouncing around in the Graphics Working Group back in the day. Alexandros as I recall was the key dev. As far as a shim goes given the effort that would have been involved and the lack of interest, it wasn't worked on.
For ARM64 and QT would a move to GLES be a "good thing?" Yes.
When it comes to graphics drivers today for arm hardware GLES is pretty universal. GLES is a standard, there is compliance through
*Shouts* ThunderX2 Workstation very loudly at this point, following by Linaro Developer Box, Macchiato bin.....
Linaro is more than Android!
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.
I personally would aim for Vulkan.
Plus there are several active efforts to do GL/GLES on top of Vulkan.
Is it true that most PCIe graphics cards (and drivers) will also support GLES as well as GL? I've seen that asserted.
As a litmus test, I don't see any GLES drivers on nVideas website. Both Vulkan and GL are there tho.
Intel supports GLES 1 and 2. And I think you can say any h/w Mesa supports, supports both GL and GLES. At least to some version level.
Rob
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.
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.
Wookey
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/
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.zanella@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.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/
linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, Nov 26, 2018 at 8:11 AM Graeme Gregory graeme.gregory@linaro.org wrote:
On Mon, 26 Nov 2018 at 14:03, Tom Gall tom.gall@linaro.org wrote:
Hi Wookey,
This was something bouncing around in the Graphics Working Group back in the day. Alexandros as I recall was the key dev. As far as a shim goes given the effort that would have been involved and the lack of interest, it wasn't worked on.
For ARM64 and QT would a move to GLES be a "good thing?" Yes.
When it comes to graphics drivers today for arm hardware GLES is pretty universal. GLES is a standard, there is compliance through
*Shouts* ThunderX2 Workstation very loudly at this point, following by Linaro Developer Box, Macchiato bin.....
Linaro is more than Android!
Sorry if this wasn't clear I wasn't just talking about Android.
You're right that when it comes to desktop graphics the nVidias and Radeons, GL will be there, as will Vulkan.
Going forward the industry has been picking up Vulkan. Vulkan however is not universal. Vulkan has hardware requirements which for whole generations of graphics hardware (like Mali 4xx) are not able to support.
As Vulkan is becoming more central to Android's Graphics strategy, it probably would be wise for the QT types to keep an eye on that.
And yes Vulkan is the future if you are not DirectX and will work on the above machines quite fine too!
Graeme
Is anyone working on open vulkan drivers for nVidia/Radeon that supports arm64?
-
Adhemerval Zanella -
Graeme Gregory -
Jammy Zhou -
Renato Golin -
Rob Herring -
Steve McIntyre -
Tom Gall -
Wookey