Re: tracking OpenGL support for specific boards
On 28/11/18 1:19 am, bret curtis wrote >> Great that you collected that dataset, and put it public. >> >> What would help further would be for such information having references >> to sources, and each information point be referencable (not only the >> dataset as a whole). >> > Isn't this already done for us here? > https://gpuinfo.org/ > > If anything, it should be used to fill in that list. Great data, thanks. I'll add that. I basically used data from the Khronos website to point me in a general direction and then I used manufacturers specifications to fill in the GL/GLES columns. > Many of those chipsets you list, as I understand, have a mesa driver > for them that support opengl and gles. > Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/ > > Keep in mind, only the proprietary drivers seem to not support opengl > while the hardware is perfectly capable of doing so. Not necessarily. If the manufacturer specifies OpenGL ES support, then - on the hardware level - it is a GLES renderer and may or may not support the entire OpenGL specification natively. It usually requires considerable work to make GLES hardware support OpenGL. Eric Anhold can tell you all about the hard work he has put into bastardising his VC4 mesa driver to make up for the lack of hardware support: https://github.com/anholt/mesa/wiki/VC4-OpenGL-support Hope that helps, Re4son > > Cheers, > Bret
Re: Upcoming Qt switch to OpenGL ES on arm64
Hi, On 2018-11-27 02:46 +, Wookey wrote: > > > > Well, that's at very least an interesting data point. So yes, they exist, > > but > > they are new and expensive. Can I assume that this means most of our arm64 > > users do not yet get to them? > Not yet, no although I think you can just buy one (Gigabyte > ThunderXstation) now. But Machiato-bin exists with working PCI and you > can buy one > (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin), and > nvidia-based hardware is available and supports GL (Jetson TX1) > (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1). There > is more hardware coming which will support GL, so it is definately not > as simple as 'available hardware is all GLES'. (Perhaps someone has > made a list in this long thread). I have previously compiled this excel sheet with data relevant to this thread: https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls Any feedback, correction and addition that could benefit this discussion would be appreciated. > > > I recall Linaro doing some work on this back > > > when it started (to make it easier to switch between GL and > > > GLES). Possibly that work never actually got done, just talked out. > > > > It would really help, indeed. > > OK. It seems that this project was started, but not completed due to a > lack of interest at the time (2012) (people just started using GLES on > dev boards/phones). It's here: https://code.launchpad.net/glproxy > And here is the spec: > https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Specs/1105/GLProxy > Perhaps it is worth resurrecting this project if it would let us > acheive the nirvana of runtime selection between GL and GLES, thus > making everyone happy. > Jammy Zhou cc:ed can say how much was/wasn't done. That is extremely interesting, anything I can do to help? > Wookey Many thanks, Re4son
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: Upcoming Qt switch to OpenGL ES on arm64
Hi, On 26/11/18 8:58 pm, Riku Voipio wrote: > On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: >> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió: > >> The real issue here is that *many* arm64 boards currently do not support >> Desktop OpenGL, but do support GLES. > The boards may or may not support Desktop GL. As far as debian is > concerned, they remain headless devices until they have free drivers. > > See, most of the propiertary GLES drivers are craptastic and don't work > with Debians kernel. Even ff you manage to dance the right kernel, device > tree and userspace combo, you may still not get the desktop enviroment > up. And nobody is going to fix the bugs you encounter. > > Debian does support Qualcomm based boards with freedreno driver, and > work is progressing with etnaviv for Vivante. Both based on Mesa and > support both OpenGL and GLES. With the MALI reverse engineering active > again, it would seem rather short-sighted and counterproductive to > put lots of energy in supporting the propiertary drivers. > I agree, hence let's do the switch and focus on developing free drivers. I fully echo your sentiment and propose a practical approach to give the best possible support to the developers whilst also providing something real to the user. In awe of the efforts that have already gone into these development activities - right now we don't have the drivers, thus we lack both OpenGL & OpenGL ES support for the majority of the arm64 platforms and considering the hard work and time it has taken already, I doubt that we will have stable full OpenGL support anytime soon. Making the switch means that we can give the hardware the proprietary support available right now, develop GLES support, roll it out, extend it to full OpenGL support and once that is reasonably mature switch back to desktop. >> Also applications using GLU[T] or glew will not be able to compile anymore >> on >> arm64. GLU[T] has not been ported to GLES, glew somehow differs in a type >> definition. > I have an Synquacer box with nvidia card running Lxqt desktop, running > fine most tasks. While none of the apps I run on it seem to be of the > Qt + GLU/glew combo, it would be unfortunate if I ever need to use them. > > Riku > Many thanks
