Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El miércoles, 28 de noviembre de 2018 12:17:22 -03 Julien Cristau escribió:
> [dropping -devel, adding mesa and kde maintainers instead]

ACK.

> On 11/27/18 5:42 PM, Steve Langasek wrote:
> > On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> >> Steve Langasek  writes:
> >>> Long ago I heard rumors of development work on mesa that would allow it
> >>> to
> >>> function as a proxy library, so that apps would link against libGL as
> >>> needed and the GL implementation would use a hardware-accelerated GLES
> >>> driver where possible, falling back to software GL where necessary.
> >> 
> >> This seems unlikely -- I believe GLES and GL have different semantics in
> >> a few places which makes implementing GL on GLES inefficient; mostly
> >> that GLES is missing stuff that GL applications often use, but I think
> >> there are places where GLES is just different, including in how GLSL
> >> works.
> > 
> > Perhaps that explains why no one ever actually succeeded in implementing
> > it, then?
> > 
> > Thanks for the context.
> > 
> >> I haven't tried, but I would expect that applications could use both GL
> >> and GLES APIs at the same time, even to the same window. If this does
> >> work with Mesa, then linking Qt against GLES wouldn't restrict
> >> applications using free drivers at least?
> > 
> > My recollection is that this becomes a practical problem of applications
> > that want to use both Qt and GL being unbuildable due to namespace
> > collisions at build time.
> 
> Do you know if there have been attempts at resolving those collisions
> upstream (either Qt or mesa / khronos)?
> 
> I seem to remember a couple of bug reports against mesa on the Debian
> side but am curious about any escalations.

The only thing I remember that sounds like this is:



"[arm] libgles2-mesa-dev and libglew-dev disagree over GLsizeiptr"

But maybe it was something else :-/

-- 
Ud. está viendo a la persona que ven nuestros clientes.
 Leyenda pegada en el espejo de una empresa.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Julien Cristau]

[dropping -devel, adding mesa and kde maintainers instead]

On 11/27/18 5:42 PM, Steve Langasek wrote:
> On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
>> Steve Langasek  writes:
> 
>>> Long ago I heard rumors of development work on mesa that would allow it to
>>> function as a proxy library, so that apps would link against libGL as needed
>>> and the GL implementation would use a hardware-accelerated GLES driver where
>>> possible, falling back to software GL where necessary.
> 
>> This seems unlikely -- I believe GLES and GL have different semantics in
>> a few places which makes implementing GL on GLES inefficient; mostly
>> that GLES is missing stuff that GL applications often use, but I think
>> there are places where GLES is just different, including in how GLSL
>> works.
> 
> Perhaps that explains why no one ever actually succeeded in implementing it,
> then?
> 
> Thanks for the context.
> 
>> I haven't tried, but I would expect that applications could use both GL
>> and GLES APIs at the same time, even to the same window. If this does
>> work with Mesa, then linking Qt against GLES wouldn't restrict
>> applications using free drivers at least?
> 
> My recollection is that this becomes a practical problem of applications
> that want to use both Qt and GL being unbuildable due to namespace
> collisions at build time.
> 
Do you know if there have been attempts at resolving those collisions
upstream (either Qt or mesa / khronos)?

I seem to remember a couple of bug reports against mesa on the Debian
side but am curious about any escalations.

Cheers,
Julien

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Steve Langasek]

On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> Steve Langasek  writes:

> > Long ago I heard rumors of development work on mesa that would allow it to
> > function as a proxy library, so that apps would link against libGL as needed
> > and the GL implementation would use a hardware-accelerated GLES driver where
> > possible, falling back to software GL where necessary.

> This seems unlikely -- I believe GLES and GL have different semantics in
> a few places which makes implementing GL on GLES inefficient; mostly
> that GLES is missing stuff that GL applications often use, but I think
> there are places where GLES is just different, including in how GLSL
> works.

Perhaps that explains why no one ever actually succeeded in implementing it,
then?

Thanks for the context.

> I haven't tried, but I would expect that applications could use both GL
> and GLES APIs at the same time, even to the same window. If this does
> work with Mesa, then linking Qt against GLES wouldn't restrict
> applications using free drivers at least?

My recollection is that this becomes a practical problem of applications
that want to use both Qt and GL being unbuildable due to namespace
collisions at build time.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Steve Langasek]

On Mon, Nov 26, 2018 at 12:21:25PM -0500, Alan Corey wrote:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?  Supply both libraries?

Because this requires providing two separate *stacks* of source packages,
one for GL and one for GLES, which from Ubuntu's experience doing this
previously for Ubuntu Touch, I can say is a non-trivial amount of
maintenance overhead.

There is some prior art here that I could provide pointers to if the Debian
Qt maintainers did decide to take this on, but best case is that you still
have two sets of about a half dozen source packages that have to be kept in
sync.

> ES gives an enormous performance boost to little machines that need it,
> desktop OpenGL is more pretty pictures.

Long ago I heard rumors of development work on mesa that would allow it to
function as a proxy library, so that apps would link against libGL as needed
and the GL implementation would use a hardware-accelerated GLES driver where
possible, falling back to software GL where necessary.

Since we are still having this conversation about having to choose between
GL and GLES at compile time, I infer that this has not come to fruition.

> On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  wrote:
> > El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> >> Hello Lisandro,
> >>
> >> TLDR: thank you for starting this discussion, it was required as it's not
> >> an easy decision to take as there is no realistic perfect solution,
> >
> > Our (team-wide) pleasure. This is something we have been digging since
> > 2015.
> >
> >> but I
> >> believe you took the wrong decision. Please consider deferring the
> >> decision to the technical committe by seeking his advice (point 6.1.3
> >> of the constitution
> >> https://www.debian.org/devel/constitution.en.html#item-6).
> >
> > Will "kind of" do. Read below.
> >
> >
> >> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> >> > It seems now clear that the general consensus seems to expect:
> >> > = Qt available for both Desktop and ES OpenGL flavours
> >> > = If no change is possible, keep arm64 with Desktop OpenGL support
> >>
> >> I'm not pleased with how this discussion was handled. First of all,
> >> you did not leave enough time for all stakeholders to participate in
> >> the discussion (started on November 22th, closed November 25th, 3 days,
> >> that's not a reasonable timeframe in particular when 2 of the 3 days
> >> were in the week-end).
> >
> > My most sincere apologies if our timeframe do not fit yours.
> >
> > Now, wrt the decision: clearly the situation is very complex, involving many
> >
> > different kinds of arm64 devices, drivers, libraries et all. People involved
> >
> > have different opinions. We so far have been the proxy between them, be it
> > on
> > bugs, IRC or whatever other channels our users have to contact us. We prefer
> >
> > not to be this proxy anymore (again, read below).
> >
> > Besides we (Qt's team) have just learned that the Desktop/ES support is not
> >
> > tied to the hardware but to the driver. That's a particularly interesting
> > point.
> >
> > So:
> >
> > To quote my original mail, the "Qt available for both Desktop and ES OpenGL
> >
> > flavours" point remains unchanged: if someone wants to make it happen [s]he
> >
> > must join the team and support it from the inside. Remember there are little
> >
> > chances for this to happen in time for Buster.
> >
> > For the second point, "If no change is possible, keep arm64 with Desktop
> > OpenGL support", we have this position: we will keep the status quo,
> > deferring
> > users who want GLES support to Ubuntu.
> >
> > *But* we are open to change this for any arch (read it: support either one
> > or
> > the other technology) as long as the decision is taken by the technical
> > committee. As I wrote before, we will keep the status quo, so if anyone is
> > interested in any change feel free to contact the TC.
> >
> > Regards, Lisandro.
> >
> > --
> > Lisandro Damián Nicanor Pérez Meyer
> > http://perezmeyer.com.ar/
> > http://perezmeyer.blogspot.com/
> >
> 
> 
> -- 
> -
> No, I won't  call it "climate change", do you have a "reality problem"? - 
> AB1JX
> Cities are cages built to contain excess people and keep them from
> cluttering up nature.
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
> 

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?

It's a Qt build-time option. This in an upstream choice, not ours and not up 
to us to fix.

> Supply both libraries?

Already answered in the thread.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Alan Corey]

Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
compile your program?  Supply both libraries?  ES gives an enormous
performance boost to little machines that need it, desktop OpenGL is
more pretty pictures.

On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  wrote:
> El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
>> Hello Lisandro,
>>
>> TLDR: thank you for starting this discussion, it was required as it's not
>> an easy decision to take as there is no realistic perfect solution,
>
> Our (team-wide) pleasure. This is something we have been digging since
> 2015.
>
>> but I
>> believe you took the wrong decision. Please consider deferring the
>> decision to the technical committe by seeking his advice (point 6.1.3
>> of the constitution
>> https://www.debian.org/devel/constitution.en.html#item-6).
>
> Will "kind of" do. Read below.
>
>
>> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
>> > It seems now clear that the general consensus seems to expect:
>> > = Qt available for both Desktop and ES OpenGL flavours
>> > = If no change is possible, keep arm64 with Desktop OpenGL support
>>
>> I'm not pleased with how this discussion was handled. First of all,
>> you did not leave enough time for all stakeholders to participate in
>> the discussion (started on November 22th, closed November 25th, 3 days,
>> that's not a reasonable timeframe in particular when 2 of the 3 days
>> were in the week-end).
>
> My most sincere apologies if our timeframe do not fit yours.
>
> Now, wrt the decision: clearly the situation is very complex, involving many
>
> different kinds of arm64 devices, drivers, libraries et all. People involved
>
> have different opinions. We so far have been the proxy between them, be it
> on
> bugs, IRC or whatever other channels our users have to contact us. We prefer
>
> not to be this proxy anymore (again, read below).
>
> Besides we (Qt's team) have just learned that the Desktop/ES support is not
>
> tied to the hardware but to the driver. That's a particularly interesting
> point.
>
> So:
>
> To quote my original mail, the "Qt available for both Desktop and ES OpenGL
>
> flavours" point remains unchanged: if someone wants to make it happen [s]he
>
> must join the team and support it from the inside. Remember there are little
>
> chances for this to happen in time for Buster.
>
> For the second point, "If no change is possible, keep arm64 with Desktop
> OpenGL support", we have this position: we will keep the status quo,
> deferring
> users who want GLES support to Ubuntu.
>
> *But* we are open to change this for any arch (read it: support either one
> or
> the other technology) as long as the decision is taken by the technical
> committee. As I wrote before, we will keep the status quo, so if anyone is
> interested in any change feel free to contact the TC.
>
> Regards, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> Hello Lisandro,
> 
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution,

Our (team-wide) pleasure. This is something we have been digging since 2015.

> but I
> believe you took the wrong decision. Please consider deferring the
> decision to the technical committe by seeking his advice (point 6.1.3
> of the constitution
> https://www.debian.org/devel/constitution.en.html#item-6).

Will "kind of" do. Read below.


> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop OpenGL support
> 
> I'm not pleased with how this discussion was handled. First of all,
> you did not leave enough time for all stakeholders to participate in
> the discussion (started on November 22th, closed November 25th, 3 days,
> that's not a reasonable timeframe in particular when 2 of the 3 days
> were in the week-end).

My most sincere apologies if our timeframe do not fit yours.

Now, wrt the decision: clearly the situation is very complex, involving many 
different kinds of arm64 devices, drivers, libraries et all. People involved 
have different opinions. We so far have been the proxy between them, be it on 
bugs, IRC or whatever other channels our users have to contact us. We prefer 
not to be this proxy anymore (again, read below).

Besides we (Qt's team) have just learned that the Desktop/ES support is not 
tied to the hardware but to the driver. That's a particularly interesting 
point.

So:

To quote my original mail, the "Qt available for both Desktop and ES OpenGL 
flavours" point remains unchanged: if someone wants to make it happen [s]he 
must join the team and support it from the inside. Remember there are little 
chances for this to happen in time for Buster.

For the second point, "If no change is possible, keep arm64 with Desktop 
OpenGL support", we have this position: we will keep the status quo, deferring 
users who want GLES support to Ubuntu.

*But* we are open to change this for any arch (read it: support either one or 
the other technology) as long as the decision is taken by the technical 
committee. As I wrote before, we will keep the status quo, so if anyone is 
interested in any change feel free to contact the TC.

Regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.