3 ms·
There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libr
by protastus 3y ago
There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libraries.
A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL.
There's a similar story here for every subsystem driver, where they insist on a brittle proprietary solutions (one branch for every chip!) that can't be upstreamed.
- zozbot234 3y agoBut Qualcomm does not currently support freedreno, it's purely a community effort. It's not Qualcomm's job to bring it to feature parity with their proprietary drivers, so the proposal to have their libraries talk to it by default is just not very sensible.
- seba_dos1 3y ago> It's not Qualcomm's job It should be if they're really serious about software support.
- protastus 3y agoYou claimed it wasn't clear how Qualcomm could help. I pointed out how they could help. There's precedent too, with ARM supporting panfrost. QC is not a low level employee lacking agency over their job description. They're a business that is free to set their strategy in response to risk and competition. The less that QC upstreams, the more risk they incur, especially with tightening security scrutiny (e.g. 2021 Cyber EO requirements). QC can also get disrupted by Mediatek doing a better job with Linux.