OpenGL vs OpenGlES on arm64

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.

Post by Wookey
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
https://lists.linaro.org/mailman/listinfo/linaro-dev

--
Regards,
Tom

Director, Linaro Consumer Group, Multimedia Working Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Graeme Gregory

2018-11-26 14:11:10 UTC

Post by Tom Gall
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!

Post by Tom Gall
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

Steve McIntyre

2018-11-26 14:45:32 UTC

*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,

--
Steve McIntyre ***@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Renato Golin

2018-11-26 14:57:35 UTC

Post by Steve McIntyre
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.

--
cheers,
--renato

Tom Gall

2018-11-26 15:08:07 UTC

On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre

Post by Steve McIntyre

*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.

Post by Steve McIntyre
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.

Post by Steve McIntyre
Cheers,
--
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Rob Herring

2018-11-26 18:44:34 UTC

Post by Tom Gall
On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre

Post by Steve McIntyre

*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! :-)

Plus there are several active efforts to do GL/GLES on top of Vulkan.

Post by Tom Gall

Post by Steve McIntyre
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

Wookey

2018-11-26 18:58:16 UTC

Post by Tom Gall
On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre

Post by Steve McIntyre
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.

Post by Tom Gall
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

--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/

Adhemerval Zanella

2018-11-26 19:26:52 UTC

Post by Tom Gall
On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre

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/

Post by Tom Gall
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/

Jammy Zhou

2018-11-27 01:42:10 UTC

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 <

Post by Adhemerval Zanella

Post by Tom Gall
On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre

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
---
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/

Post by Tom Gall
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
https://lists.linaro.org/mailman/listinfo/linaro-dev

Tom Gall

2018-11-26 14:57:24 UTC

On Mon, Nov 26, 2018 at 8:11 AM Graeme Gregory

*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.