Hi everybody! El martes, 25 de septiembre de 2018 11:07:31 -03 Raphael Hertzog escribió: > 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-graphic > > s-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. Sure thing. I even wrote to you on IRC on #debian-devel but you might have missed it. I want to stress a point here: in my reply below I might sound too negative, but I have been struggling with this subject for at very least a couple of years now. The big issue behind this is lack of proper data and industry definitions in terms of what is the real trend behind all this. That being said every data that can help us make a better decision will be highly appreciated. > 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 That's actually interesting data. > > 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. I would disagree with that, specially with the use of QML, but the arm64 server scenario is definitely not a fully deployed one yet so there is lot of room for changes. But I would *love* to have one more data point: how many of those boards require the proprietary video card vendor's headers to be present at Qt build time? Yes, some of them need to be present at qtbase's build time in order to fully work (or even work at all). Take a look at [experimental's] qtbase build. Look for "QPA backends" → "EGLFS details". As you can see there is EGL support, but some vendors require specific proprietary code to be present at build time. Even if it where not proprietary they are self-excluding, ie, you can only pick one at a time. [experimental's] <https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src&arch=amd64&ver=5.11.2%2Bdfsg-2&stamp=1537603343&raw=0> So the question is: if we do the switch, how many boards we will really support? And actually, did the switch to EGL really served the other arm* archs? That really depends on the number of bards that do not require proprietary stuff around at build time. Side note: I have just created #909579 to see if we can add Vulkan support without breaking anything else. > > More objectively, Ubuntu did that switch two years ago and there have > > been no issues reported in launchpad as a result of it. This is not actually true. There's what I wrote above *and* the fact that this breaks API/ABI. How so? Well, EGL is not compatible with GLU/GLUT, on which many Qt-based applications rely upon, see [glut]. [glut] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798408#67> Note that at the moment I was convinced to switch arm64 and we did know of few packages that had issues. That changed. So, let's suppose we get enough data to decide it's a good idea to switch arm64. We would need a full blown transition to get this done, plus proper bug reports to the affected packages in time plus either a soname bump or at very very least changing the binary name libqt5core5a to libqt5core5b. Ideally we would just do this, but changing SONAME should be the right thing to do. And that means other distros will probably need to follow. Can our current team deal with all that now that freeze is somewhat near and autopkgtest have become, in terms of maintainer time, a problem more than a solution? We are a very small team that not only supports 30+ library packages but now also has to deal with other people's faulty autopkgtests to get a transition done. > 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. That's, I'm afraid, the normal result when talking about video on ARM. > 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. Right, and we are currently short of proper man power. > 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). Timo was an active part of this team at that point too. He is also a DD. Cheers, Lisandro. -- You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now. Linus Benedict Torvalds. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Attachment:
signature.asc
Description: This is a digitally signed message part.