Re: Bug#881333: tracking OpenGL support for specific boards
pe 30. marrask. 2018 klo 1.26 Lisandro Damián Nicanor Pérez Meyer (perezme...@gmail.com) kirjoitti: > > > 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. > > So the real place which should be fixed is, somehow, in Qt itself, and > preferably by not hacking libs. Surely the best solution would indeed be getting https://bugreports.qt.io/browse/QTBUG-36829 fixed, but there is unfortunately no reported recent progress. -Timo
Re: tracking OpenGL support for specific boards
> > 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 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: > When Eric jumped from Intel to Broadcom, I was there at the beginning of his VC4 work doing testing and getting OpenMW running on the RPi. One of our conversations revolved around why only GLES support and not full GL support in the binary blob and his answer was that VC4 can do both but only to a point, it depends entirely on what the hardware is capable of. VC4 is fully capable of OpenGL 2.1 but with a few more extensions that were GLES 2.0 specific. No bastardisation. His biggest hurdle (still?) is dealing with the fact that the VC4 has no memory space protection because there is no MMU. He has to use a CMA which is _very_ slow and has had to put in a ton of work to get that working. [1] That has nothing to do with what the GPU was capable of in terms of GL/GLES. You can't have GLES 2.0 without first having GLES 1.1 which is backwards compatible with OpenGL 1.5 in hardware. That is why I stated that it is the driver developer that makes the decision as to what is exposed which is a cost/price decision of the company pushing the hardware. If they only have to target GLES then why expose GL? Less time to market and less money spent in development? Take for example the S3TC opengl extension: EXT_texture_compression_s3tc This is not supported in hardware which is the reason, even after the patent was expired, that Eric (or anyone) could not implement it. Broadcom simply didn't bother (cost cutting?). So if you ever have texture that loads in with a S3TC, all you'll see is pink (or whatever is used as alpha). There is no, if extension doesn't exist, we'll just emulate it in software in VC4. I would be seriously flabbergasted if there was a chipset out there that supported GLES2, that on hardware, wasn't capable of at least OpenGL 1.5. I'm talking about on hardware, not a proprietary binary blog that only exposes GLES. > https://github.com/anholt/mesa/wiki/VC4-OpenGL-support > I know, I've posted this several time in previous Qt related threads. :) Cheers, Bret [1] https://dri.freedesktop.org/docs/drm/gpu/vc4.html
Bug#881333: Info received (Bug#881333: tracking OpenGL support for specific boards)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Qt/KDE Maintainers If you wish to submit further information on this problem, please send it to 881...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 881333: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881333 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#881333: tracking OpenGL support for specific boards
El jueves, 29 de noviembre de 2018 19:00:28 -03 Re4son escribió: [snip] > > 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 Ah, so there was the gotcha. I was really surprised to learn that it was "just" a driver issue. Clearly the Desktop OpenGL support is almost there, but not entirely. So the real place which should be fixed is, somehow, in Qt itself, and preferably by not hacking libs. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
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: tracking OpenGL support for specific boards
On Tue, Nov 27, 2018 at 3:58 PM Stefan Monnier wrote: > > >> 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/ > > I don't see any reference to sources. > Also I see it as "Ubuntu" and "Arch" as OSes, whereas I'd rather see the > status of the underlying driver so I can easily extrapolate from it to > what will happen in any particular GNU/Linux distribution. > > The database describes itself as "an online tool for developers that > want to check out GPU hardware capabilites", so it seems to be focused > on hardware, whereas I think we need something that focuses on > the drivers. Have you looked at https://mesamatrix.net/ ? That is a list of drivers, not exhaustive because VC4 and other's are not currently tracked. However Freedreno that supports all Adreno A4XX hardware does have a debian package for armel and armhf. Is that perhaps something to look into? Here is the wikipedia page for Adreno and it lists the opengl support per chipset: https://en.wikipedia.org/wiki/Adreno ^-- it's fairly complete and says that they too fall under Freedreno Then there is this for Mali400/450: https://gitlab.freedesktop.org/lima/mesa Cheers, Bret
Re: tracking OpenGL support for specific boards
> > 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. > > 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. 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. Cheers, Bret
Re: tracking OpenGL support for specific boards
Quoting Re4son (2018-11-27 11:38:14) > 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. 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). In other words, your data gets 2 stars: https://5stardata.info/en/ I maintain https://wiki.debian.org/CheapServerBoxHardware and have for a long time wanted to make that 5-star data (currently that has 3 stars). Would be great to include your dataset in that, but I would then need to know the sources for the datapoints to be able to verify. Also, ideal would be that you maintain your dataset yourself as 5-star reusable data instead of me needing to maintain a fork. A user-visible benefit of 5-star data is the possibility for not only browsing it as tabular data, but also navigating multiple dimensions e.g. like https://kumu.io/DigLife/digital-life-collective#our-network Please tell me if interested in helping out, and I will provide concrete examples of how to optimally organize data, as soon as I get it documented for my own work. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
