Control: reopen -1 hertzog@debian.org Hello, On Mon, 13 Nov 2017, Lisandro Damián Nicanor Pérez Meyer wrote: > > Could you please rebuild qtbase with OpenGL ES acceleration on ARM64 > > instead so as to provide a better user experience on these devices? > > As discussed on IRC, it means beaking ABI and also arm64 is likely to > have DesktopOpenGL support as per > https://nullr0ute.com/2017/09/the-state-of-open-source-accelerated-graphics-on-arm-devices/ > > So for the moment is a non-go. I asked on IRC and mitya57 told me that we can revisit this decision. I'm not an expert in this topic but in Kali we have quite some experience in providing Kali images for specific ARM devices. Right now we are working on getting Kali working in the Gemini PDA and this bug is a blocker: https://store.planetcom.co.uk/products/gemini-pda-1 I asked a few questions to the person working on this project. My questions were those: > Can we reasonably say that most arm64 boards have OpenGL ES but no > regular OpenGL? Can you provide a somewhat up-to-date list to back up > this fact? > Can a QT compiled for OpenGL ES still benefit from some hardware > acceleration on a board with full OpenGL support? Here's the answer that I got from Re4son: > I haven't come across any arm64 chipset with an OpenGL enabled GPU apart > from 2 NVIDIA's CUDA based platforms. I've heard about the idea but they > were merely academic and nothing seems to have come out of it. Quite > the opposite - everybody seem to toy with the idea of moving to Vulkan > rather than GL. > The core principle is to provide packages that match the GPU's attached > to the architecture and according to the following stats, all but 2 of > the GPU's attached to arm support only GLES: > > https://www.khronos.org/conformance/adopters/conformant-products/opengles > https://www.khronos.org/conformance/adopters/conformant-products/opengl > > I haven't experimented with it, but according to the specifications > OpenGL GPU's are capable of running GLES applications albeit not to the > full potential of the hardware. The only scenario where I could see that > being an issue is when someone puts a GL enabled GPU in an arm64 server > and I cannot imagine that they are craving top shelf 3D acceleration of > their qt applications. > More objectively, Ubuntu did that switch two years ago and there have > been no issues reported in launchpad as a result of it. He wanted to get some confirmation of all this but he did not manage to get any response from the experts he tried to contact. Based on all this, it seems to me that we would better served by using OpenGL ES on arm64. If we don't do this, we should likely be providing conflicting packages to support both QT with OpenGL and QT with OpenGL ES but I can see that becoming rather hard to handle. And the fact that Ubuntu made the switch is reassuring: it can be done and it's likely the most useful choice right now. I'm ccing the Ubuntu developer who made the switch in case he can add something useful to this discussion (the change happened in qtbase-opensource-src (5.5.1+dfsg-17ubuntu2~2 in yakkety in 2016). 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