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