Bug#881333: 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
Bug#881333: 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
Bug#881333: 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
