Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hey > Here I agree with Luke Kenneth Casson Leighton’s opinion [1]. > > I think we should aim to provide the best possible experience with the free > software ecosystem. The experience with proprietary drivers should be the > second priority, if priority at all. > AFAIU by building Qt with GLES we'd still be able to make use of mesa as it provides both GL and GLES capabilities, while also allowing Qt to make use of blobs if a user so chooses. > > By choosing to build Qt with GLES on ARM64, we make Debian a more > > attractive platform for vendors who'd like to target ARM64 boards. > > We should make it attractive for vendors to release their code under > a free software (DFSG) license. That way anyone would be able to hack on it > and add missing support for a different OpenGL variant, if needed. > > That said, as Lisandro announced, we will be happy to make any decision > if there is either a consensus or a TC decision about it. > Ack. Cheers Rohan Garg
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
On Wed, Nov 28, 2018 at 7:30 AM Lisandro Damián Nicanor Pérez Meyer wrote: > Just curious: is there any project alive for the PowerVR SGX530 ? There used to be a very brief effort around PowerVR devices but it looks like that has died now. Some of the project site was captured by archive.org and lkcl's part of the work is still on his site. If anyone wants to start a new reverse engineering effort, I strongly suggest to start it on a hosting service close to the existing Xorg/etc communities that will last long-term (like freedesktop.org/x.org) instead of one that might disappear at any moment. https://wiki.debian.org/Mobile#software-drivers https://web.archive.org/web/20170620135604/http://powervr.gnu.org.ve:80/doku.php https://libreplanet.org/wiki/Group:PowerVR_drivers http://lkcl.net/powervr/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
El martes, 27 de noviembre de 2018 17:19:32 -03 Dmitry Shachnev escribió: > Hi Rohan! > > On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote: > > [...] > > > > I concur here. It was correctly pointed out in another reply that by using > > OpenGL we're specifically catering to software that doesn't support > > GLES while making performance worse for mature applications that > > do implement both OpenGL and GLES. The reality of the situation is that > > the market currently favors GLES over GL on ARM SBC's, delivered with > > proprietary blobs. I think a more pragmatic view of this reality would be > > to deliver the best FOSS user experience that's possible with the > > proprietary drivers while the open source drivers are being improved. To > > that extent, by switching to GLES we improve the overall situation since > > OpenGL applications can fall back to software rendering via mesa on > > platforms where mesa does not support the GPU. > > Here I agree with Luke Kenneth Casson Leighton’s opinion [1]. > > I think we should aim to provide the best possible experience with the free > software ecosystem. The experience with proprietary drivers should be the > second priority, if priority at all. I can't but agree here. -- Una vez que hemos eliminado lo imposible, lo que queda, por improbable que parezca, es la verdad. Sherlock Holmes 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: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
El domingo, 25 de noviembre de 2018 21:18:39 -03 Paul Wise escribió: > On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote: > > Both Dmitry and I just learned that the RPI has the VC4 driver which > > enables it to do hardware acceleration for Desktop OpenGL, we must admit > > that this is a game changer in many ways, even if we are talking on just > > one board (but quite an ubiquitous one). > > I expect this also applies to any driver in (or soon to be in) mesa, > including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv > (Vivante), Tegra etc. Drivers only supporting GLES seems to be a > something that happens only with the proprietary drivers. I don't have > any ARM devices with GPUs to be able to test this though. Just curious: is there any project alive for the PowerVR SGX530 ? Yes, they are mostly found on armhf devices, but as far as I know there is only the proprietary (and crappy) driver. -- La vida no se mide por la cantidad de veces que respiramos, sino por la cantidad de momentos que nos quitan la respiración. Anónimo 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: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hi Rohan! On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote: > [...] > > I concur here. It was correctly pointed out in another reply that by using > OpenGL we're specifically catering to software that doesn't support > GLES while making performance worse for mature applications that > do implement both OpenGL and GLES. The reality of the situation is that > the market currently favors GLES over GL on ARM SBC's, delivered with > proprietary blobs. I think a more pragmatic view of this reality would be to > deliver the best FOSS user experience that's possible with the proprietary > drivers while the open source drivers are being improved. To that extent, > by switching to GLES we improve the overall situation since OpenGL > applications can fall back to software rendering via mesa on platforms > where mesa does not support the GPU. Here I agree with Luke Kenneth Casson Leighton’s opinion [1]. I think we should aim to provide the best possible experience with the free software ecosystem. The experience with proprietary drivers should be the second priority, if priority at all. > By choosing to build Qt with GLES on ARM64, we make Debian a more > attractive platform for vendors who'd like to target ARM64 boards. We should make it attractive for vendors to release their code under a free software (DFSG) license. That way anyone would be able to hack on it and add missing support for a different OpenGL variant, if needed. That said, as Lisandro announced, we will be happy to make any decision if there is either a consensus or a TC decision about it. [1]: https://lists.debian.org/debian-devel/2018/11/msg00622.html -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hey On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog wrote: > > 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, 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). > Having worked on multiple ARM boards over the past 3 years, I agree very strongly with Raphael. > 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). I was aware of the discussion but did not > had the time to chime in, yet I was the person who re-opened the bug > #881333 in the first place. > As the person who opened #881333, I completely agree. I've been on vacation the past 10 days and haven't had a opportunity to chime in. > I also invited someone else who is working on a concrete project involving > Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available > now but he also did not have the time to contribute to the discussion. > I've had multiple concrete projects involving KDE, Qt and ARM over the past few years, over multiple ARM platforms such as the ODROID C1, C2 and the Pinebook. With my KDE hat on, we have a strong stake in having Plasma perform decently well on these devices. > Then I have read the whole discussion and I don't have the feeling that > any consensus has been reached. It was largely driven by Andy Simpkins > who explained his "gut feeling" as a tinkerer of arm* boards/devices and > Bret Curtis who contributes to some applications with very specific OpenGL > needs. While I value their contribution to the discussion, they both > represent very specific classes of users. > > What I remember from this discussion is that the Windows build of Qt > use GLES 2 by default. It would have been interesting to find out the > rationale for this... because maybe the right decision for us would be > to switch to GLES 2 by default as well (on all architectures as jcristau > suggested). Someone else who likely also tried to ensure Qt for Windows is > usable on most hardware made that choice. > > We got confirmation from many persons that almost all cards benefitting > from Desktop OpenGL would also work with OpenGL ES. So in terms of > hardware support, picking OpenGL ES is the right choice. In terms of > sofware support, it looks like that Desktop OpenGL is better as there > are a few applications that only work with Desktop OpenGL. > > Software can be fixed/improved to also work with OpenGL ES. However > hardware, once bought, cannot be fixed to support Desktop OpenGL > when it has been designed for OpenGL ES only. > I concur here. It was correctly pointed out in another reply that by using OpenGL we're specifically catering to software that doesn't support GLES while making performance worse for mature applications that do implement both OpenGL and GLES. The reality of the situation is that the market currently favors GLES over GL on ARM SBC's, delivered with proprietary blobs. I think a more pragmatic view of this reality would be to deliver the best FOSS user experience that's possible with the proprietary drivers while the open source drivers are being improved. To that extent, by switching to GLES we improve the overall situation since OpenGL applications can fall back to software rendering via mesa on platforms where mesa does not support the GPU. > When taking all this into account, I believe that the right solution is > to use OpenGL ES on all architectures. This will provide the required > incentives for application developers who stick only to Desktop OpenGL > to support OpenGL ES (even it it's at the cost of using some intermediary > layer like https://github.com/p3/regal) and would maximize hardware > support on all architectures. > > That said, I'm fine with a decision to change only arm64 since that's > an architecture were devices that support only OpenGL ES are in the > majority. > By choosing to build Qt with GLES on ARM64, we make Debian a more attractive platform for vendors who'd like to target ARM64 boards. Cheers Rohan Garg
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hi, On 26/11/18 11:54 pm, Riku Voipio wrote: > On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote: >> were in the week-end). I was aware of the discussion but did not >> had the time to chime in, yet I was the person who re-opened the bug >> #881333 in the first place. > >> I also invited someone else who is working on a concrete project involving >> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available >> now but he also did not have the time to contribute to the discussion. >> Software can be fixed/improved to also work with OpenGL ES. However >> hardware, once bought, cannot be fixed to support Desktop OpenGL >> when it has been designed for OpenGL ES only. > Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27, > featuring Mali-T880. The hardware is not OpenGL ES only .. the > propiertary driver is. Mesa-based panfrost driver should support both > OpenGL and OpenGL ES: > > https://gitlab.freedesktop.org/panfrost > > The open source driver is of course not ready... ...but neither is > Debian ES 2.0. In the long run, making the driver ready is time better > spent than time spent trying to make Debian more friendly to a class > of propiertary drivers. I fully agree again. Looking at the lengthy progress so far and the limited resources available, I suggest supporting the development by switching to GLES and work on the drivers to support that first. Once that has been achieved we can aim for full OpenGL support and then we can switch back to desktop if there is actual user demand. I'm not suggesting to make Debian more friendly to proprietary drivers. The exact opposite: switching to GLES to fill the void will give us time to aim for one milestone at a time. The vast majority of devices we are talking about are embedded systems, let's aim to bring them the drivers and interfaces that have been designed for embedded systems before we reach for the stars. A lot of the discussion in this thread seems off topic and academic but I’m confident that the above approach is what we need to move on. > Riku > Many thanks
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote: > were in the week-end). I was aware of the discussion but did not > had the time to chime in, yet I was the person who re-opened the bug > #881333 in the first place. > I also invited someone else who is working on a concrete project involving > Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available > now but he also did not have the time to contribute to the discussion. > Software can be fixed/improved to also work with OpenGL ES. However > hardware, once bought, cannot be fixed to support Desktop OpenGL > when it has been designed for OpenGL ES only. Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27, featuring Mali-T880. The hardware is not OpenGL ES only .. the propiertary driver is. Mesa-based panfrost driver should support both OpenGL and OpenGL ES: https://gitlab.freedesktop.org/panfrost The open source driver is of course not ready... ...but neither is Debian ES 2.0. In the long run, making the driver ready is time better spent than time spent trying to make Debian more friendly to a class of propiertary drivers. Riku
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Quoting Raphael Hertzog (2018-11-26 12:37:57) > Software can be fixed/improved to also work with OpenGL ES. However > hardware, once bought, cannot be fixed to support Desktop OpenGL when > it has been designed for OpenGL ES only. Is some _hardware_ really "designed for OpenGL ES only"? I guess you mean that some hardware is only supported by non-free firmware/software hardcoded which is designed for OpenGL ES only". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
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, 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). 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). I was aware of the discussion but did not had the time to chime in, yet I was the person who re-opened the bug #881333 in the first place. I also invited someone else who is working on a concrete project involving Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available now but he also did not have the time to contribute to the discussion. Then I have read the whole discussion and I don't have the feeling that any consensus has been reached. It was largely driven by Andy Simpkins who explained his "gut feeling" as a tinkerer of arm* boards/devices and Bret Curtis who contributes to some applications with very specific OpenGL needs. While I value their contribution to the discussion, they both represent very specific classes of users. What I remember from this discussion is that the Windows build of Qt use GLES 2 by default. It would have been interesting to find out the rationale for this... because maybe the right decision for us would be to switch to GLES 2 by default as well (on all architectures as jcristau suggested). Someone else who likely also tried to ensure Qt for Windows is usable on most hardware made that choice. We got confirmation from many persons that almost all cards benefitting from Desktop OpenGL would also work with OpenGL ES. So in terms of hardware support, picking OpenGL ES is the right choice. In terms of sofware support, it looks like that Desktop OpenGL is better as there are a few applications that only work with Desktop OpenGL. Software can be fixed/improved to also work with OpenGL ES. However hardware, once bought, cannot be fixed to support Desktop OpenGL when it has been designed for OpenGL ES only. When taking all this into account, I believe that the right solution is to use OpenGL ES on all architectures. This will provide the required incentives for application developers who stick only to Desktop OpenGL to support OpenGL ES (even it it's at the cost of using some intermediary layer like https://github.com/p3/regal) and would maximize hardware support on all architectures. That said, I'm fine with a decision to change only arm64 since that's an architecture were devices that support only OpenGL ES are in the majority. This is not a easy decision to make but we have a dedicated body to help maintainers find the best technical decision when there are pros/cons in both solutions, it's called the technical committee. Please consider seeking their advice before taking your decision. > Both Dmitry and I just learned that the RPI has the VC4 driver which enables > it to do hardware acceleration for Desktop OpenGL, we must admit that this is > a game changer in many ways, even if we are talking on just one board (but > quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use > Ubuntu. I don't see why this affects the decision in any way. AFAIK the VC4 driver also enables hardware acceleration for OpenGL ES. And this is only relevant for the RPI3 which is the only arm64 hardware. Bret Curtis clearly explained that we do get good performances on older RPI (armhf-based) precisely because of the VC4 driver being able to leverage OpenGL ES too. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote: > Both Dmitry and I just learned that the RPI has the VC4 driver which enables > it to do hardware acceleration for Desktop OpenGL, we must admit that this is > a game changer in many ways, even if we are talking on just one board (but > quite an ubiquitous one). I expect this also applies to any driver in (or soon to be in) mesa, including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv (Vivante), Tegra etc. Drivers only supporting GLES seems to be a something that happens only with the proprietary drivers. I don't have any ARM devices with GPUs to be able to test this though. -- bye, pabs https://wiki.debian.org/PaulWise
