Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Jammy Zhou
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
> >>  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 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

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Wookey
On 2018-11-26 09:08 -0600, Tom Gall wrote:
> On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre
>  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 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
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Rob Herring
On Mon, Nov 26, 2018 at 9:10 AM Tom Gall  wrote:
>
> On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre
>  wrote:
> >
> > On Mon, Nov 26, 2018 at 02:11:10PM +, Graeme Gregory wrote:
> > >On Mon, 26 Nov 2018 at 14:03, Tom Gall  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 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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Tom Gall
On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre
 wrote:
>
> On Mon, Nov 26, 2018 at 02:11:10PM +, Graeme Gregory wrote:
> >On Mon, 26 Nov 2018 at 14:03, Tom Gall  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 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 McIntyresteve.mcint...@linaro.org
>  Linaro.org | Open source software for ARM SoCs
>


-- 
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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Renato Golin
On Mon, 26 Nov 2018 at 14:46, Steve McIntyre  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.

-- 
cheers,
--renato
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Tom Gall
On Mon, Nov 26, 2018 at 8:11 AM Graeme Gregory
 wrote:
>
> On Mon, 26 Nov 2018 at 14:03, Tom Gall  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?

-- 
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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Steve McIntyre
On Mon, Nov 26, 2018 at 02:11:10PM +, Graeme Gregory wrote:
>On Mon, 26 Nov 2018 at 14:03, Tom Gall  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,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread Graeme Gregory
On Mon, 26 Nov 2018 at 14:03, Tom Gall  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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OpenGL vs OpenGlES on arm64

2018-11-26 Thread 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
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  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



-- 
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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev