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/
Attachment:
signature.asc
Description: PGP signature