Collabora developers have not stopped working and it is that in recent months they have given much to talk about and this time it is not the exception because recently announced the announcement of the implementation in the Panfrost driver of OpenGL 3.1 support for Midgard GPUs (Mali-T6xx, Mali-T7xx, Mali-T8xx) and Bifrost GPUs (Mali G3x, G5x, G7x), as well as OpenGL ES 3.0 support for Bifrost GPUs.
These changes expected to be included in the Mesa 21.0 release, which is currently in the launch candidate stage.
It should be remembered that Collabora developers have worked for a long time on the implementation of controllers for tables and an example of this is the past Gallium tabletop controller, that implements an intermediate layer to organize OpenCL 1.2 and OpenGL 3.3 API about drivers with DirectX 12 (D3D12) support and that their source code is released under the MIT license.
The proposed controller allows you to use Mesa on devices which are not initially compatible with OpenCL and OpenGL and also as a starting position to port OpenGL / OpenCL applications to work on D3D12.
On the part of the new Panfrost driver, it is observed that GPU Midgard and Bifrost share common data structures for fixed functions, but Bifrost uses a fundamentally different set of instructions, which makes synchronous implementation of functionality for GPU data difficult.
Architecturally, Bifrost shares most of its fixed-function data structures with Midgard, but introduces a new set of instructions. Our work to introduce OpenGL ES 3.0 to Bifrost reflects this division.
Some fixed-function features, such as instantiation and transform feedback, worked without any specific Bifrost change, as we already did in Midgard. Other shadowing features, such as uniform buffer objects, required "from scratch" implementations in the Bifrost compiler, a task made easy by the compiler's mature intermediate representation with first-class build support.
For example, the fixed functions already implemented for Midgardsuch as 'transformation feedback', can be transferred to Bifrost without changes, while features like Multiple Render Targets (MRT) are limited to some specific Bifrost changes.
At the same time, other shader operations, such as unified buffer objects, require a fresh implementation for the Bifrost shader compiler.
This follows OpenGL ES 3.0 support in Midgard that landed over the summer, as well as initial OpenGL ES 2.0 support that recently debuted for Bifrost. OpenGL ES 3.0 is now tested on Mali G52 in Mesa's Continuous Integration, achieving a 99.9% pass rate in the corresponding DrawElements Quality Program tests.
However, other features, such as multiple rendering targets, required specific code from Bifrost while taking advantage of other code shared with Midgard. Still, the work progressed much faster the second time around, a testament to the power of shared codes. But you don't need to limit your swap to just Panfrost GPUs; Open source drivers can share code between vendors.
In addition, in the announcement it is mentioned that some of the duplication of work was avoided by using an intermediate representation in the compiler, which, together with the shared code, significantly speeds up development and that with this approach the code can be used not only for a family of GPUs, but also for different controllers.
In particular, the developers mention that in order to implement OpenGL on desktop systems, the Panfrost driver required the use of ready-to-use Mesa components, while the proprietary driver for Mali is only limited to supporting only OpenGL ES.
However, the OpenGL 3.1 desktop support is almost "free" for us as an upstream Mesa controller by leveraging the common infrastructure.
Finally, if you are interested in knowing more about it about the new Panfrost implementation proposed by Collabora developers, you can check the details In the following link.