Progress on mainline efforts

[vinibali]

Hello there!
Wow, I didn't expect to find something like this. It's a great project so far!
How far is this from making some of the driver part of the mainline kernel development?
Best regards

[goldelico]

Well, that is quite a long distance...
The main reason is that we have multiple DDK versions for the kernel driver and different SoC. So there is no single driver for all of them, although the versions have a lot in common.
If someone would volunteer to merge them into a "generic" DDK (where for example some device tree property or some runtime detected value controls the variance), chances would be much higher to make it acceptable for mainline.

[mirh]

I believe kernel won't/cannot accept code that doesn't have a corresponding free userspace using it.

For as much as maybe "shimming via gallium" and "it's a first step and we are desperate" could be persuasive enough for staging?
https://github.com/maemo-leste-upstream-forks/mesa/tree/maemo/chimaera
https://github.com/mobiaqua/mesa-sgx (are there more close to upstream solutions?)

@StaticRocket is there anything in reserve for the foreseeable future?

[goldelico]

I think the PVR Rogue (successor of SGX) now has an upstream driver while user-space still uses closed source. But I may be wrong. So if there is a path to get something into staging, I'd be happy.

[StaticRocket]

(Going to try and avoid saying anything that will get me in trouble here.) Yeah, quite a lot of moving parts. At this point IMG has stopped all development on SGX. We've informed them of the community interest to see it upstream. At this point they are aware, but they have expressed no interest in adding anything older than AXE.

As far as unifying the existing driver, there's so much that's defed out at compilation time, it would require a huge rewrite - switching everything as simple as core errata to runtime config structures. Not something I see anyone doing for these older devices.

I've been able to pry open the mesa patches. Those adopt the upstream license and are actually rebranded as part of the build process. I've tried splitting that out into it's own interface available at: https://gitlab.freedesktop.org/StaticRocket/mesa/-/tree/powervr/23.2.1?ref_type=heads

That gets this thing a little closer to being evergreen, but it uses a new interface to avoid being tied to a specific version of mesa and isn't applicable to other vendor forks.

As of right now, it's pretty bleak. I want to see these devices live longer, but because of licensing and lack of motion on IMGs side, these things have a hard expiration date. In the event we no longer release binaries and the ABI compatibility for those old releases starts to fail, there will be no fallback. You could try to keep them running with some library compatibility shims but it's going to be weird.

(Also, AXE has a completely open userspace. Only the firmware is closed for now.)

[vinibali]

(Going to try and avoid saying anything that will get me in trouble here.) Yeah, quite a lot of moving parts. At this point IMG has stopped all development on SGX. We've informed them of the community interest to see it upstream. At this point they are aware, but they have expressed no interest in adding anything older than AXE.

@StaticRocket, are you talking about the PowerVR Mesa driver in this case, right?
https://docs.mesa3d.org/drivers/powervr.html

[StaticRocket]

Yeah. Both the mesa and upstream kernel components.

(Though I know the community has attempted to add the firmware loader for 8XE in KM.)

[vinibali]

Well, that is quite a long distance... The main reason is that we have multiple DDK versions for the kernel driver and different SoC. So there is no single driver for all of them, although the versions have a lot in common. If someone would volunteer to merge them into a "generic" DDK (where for example some device tree property or some runtime detected value controls the variance), chances would be much higher to make it acceptable for mainline.

@goldelico do I understand well, that different drivers (DDK?) are shipped for each SoC by the manufacturers?
so ImgTec is not shipping any universal binary driver to the end users, just giving the SDK(?) to Ti, Beaglebone or Mediatek and so on? sorry I don't understand how ImgTec is shipping it's binary.

I think the PVR Rogue (successor of SGX) now has an upstream driver while user-space still uses closed source. But I may be wrong. So if there is a path to get something into staging, I'd be happy.

Yes, the PowerVR userspace Vulkan driver is even shipped by Mesa

[vinibali]

Yeah. Both the mesa and upstream kernel components.

(Though I know the community has attempted to add the firmware loader for 8XE in KM.)

@StaticRocket which kernel driver are you targeting with the mesa repo you sent?

[StaticRocket]

The repo I sent was for the dummy gallium shim that the proprietary um and out of tree km use.

[goldelico]

Am 17.11.2024 um 19:05 schrieb vinibali ***@***.***>: Well, that is quite a long distance... The main reason is that we have multiple DDK versions for the kernel driver and different SoC. So there is no single driver for all of them, although the versions have a lot in common. If someone would volunteer to merge them into a "generic" DDK (where for example some device tree property or some runtime detected value controls the variance), chances would be much higher to make it acceptable for mainline. @goldelico <https://github.com/goldelico> do I understand well, that different drivers (DDK?) are shipped for each SoC by the manufacturers? so ImgTec is not shipping any universal binary driver to the end users, just giving the SDK(?) to Ti, Beaglebone or Mediatek and so on? sorry I don't understand how ImgTec is shipping it's binary. I think the PVR Rogue (successor of SGX) now has an upstream driver while user-space still uses closed source. But I may be wrong. So if there is a path to get something into staging, I'd be happy. Yes, the PowerVR userspace Vulkan driver is even shipped by Mesa — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOUPIXQ57MNGTO6UPQDRT2BDLGDAVCNFSM6AAAAABQ7WFCPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBRGQYTANJYHA>. You are receiving this because you were mentioned.

For the structure: 1. there are PowerVR SGX (also called version 5 like in 520, 540, 544 etc.) and PowerVR Rogue (also called Version 6) 2. these have been provided as VHDL building blocks to the SoC designers. 3. the SoC designers (Texas Instruments, Apple (iPhone 3GS?), Ingenic, Intel and others) have integrated this VHDL blocks into their SoC (with different interfaces to memory, dma, clocks, resets) 4. the SoC designers also bought different revisions of the SGX5, e.g. 530v121 or 530v125 in different OMAP3 versions 5. Imagination provided a DDK with some common "helper" library and code for kernel drivers and user-space and a binary firmware blob [this is what you have correctly understood] - Imagination isn't shippingthis to end-users at all 6. SoC designers integrated all this and published these at different times (based on different revisions) 7. so we end up with a list of SoC having different versions/revisions of the SGX5 hardware and a kernel driver and user-space for each of them - sort of snapshots 8. for this project here [openpvrsgx-devgroup/linux_openpvrsgx] we have collected several source codes of kernel drivers, added some general master driver (pvrsrvkm) and made it a CONFIG choice which kernel DDK is built. 9. user-space is also different for different SoC and SGX revisions 10. user-space is also distributed as binary only and links against specific versions of e.g. libc 11. unfortunately we do not have the same set of user-space code as for the kernel drivers and it was not the target of this project to collect these as well 12. best compatibility and availability of kernel and user-space is AFAIK given for TI omap processors Hope this helps a little to understand the complexity and challenges. It would be much easier if source code for user-space, firmware, compilers, and the programming reference of the SGX5 were also open source. Basically Imagination has this in-house for sure or SoC designers could not have built the snapshots we have collected. And if SoC vendors provided enough documentation of their interfacing part (most have it well enough to work with). If it were open we could take and maintain a single set of - kernel driver - user-space - GPU firmware which can be compiled for any SoC which has SGX5 integrated. So that remains the dream...

[vinibali]

I believe kernel won't/cannot accept code that doesn't have a corresponding free userspace using it.

For as much as maybe "shimming via gallium" and "it's a first step and we are desperate" could be persuasive enough for staging? https://github.com/maemo-leste-upstream-forks/mesa/tree/maemo/chimaera https://github.com/mobiaqua/mesa-sgx (are there more close to upstream solutions?)

@StaticRocket is there anything in reserve for the foreseeable future?

@mirh in this branch many commits are seems to be some cooperation by ImgTec according to the commit message

[vinibali]

11. unfortunately we do not have the same set of user-space code as for the kernel drivers and it was not the target of this project to collect these as well

thanks @goldelico!
I understand this now

[mirh]

It's just some shrewd forward port of the oldish patches for MT8173 chromebooks.
Which yes, is part of a collaboration, but they are EOL since a few years.

[xerpi]

Speaking on behalf of the 'Vita Linux' project (the PlayStation Vita features an SGX543 MP4+ GPU), we are also very interested in having open-source kernel and user-space (Mesa) drivers for the SGX series.
I can help with reverse engineering the (compiled) kernel-side and userspace (compiler) that the PSVita uses.
xerpi/vita-linux-loader#4 (comment)

[goldelico]

Welcome to this project!
As far as I could find out the Vita has a custom developed SoC.
What we would need to have is some vendor setup that is known to work and have at least the kernel driver as source. I have looked into the kernel tree on github but haven't seen a copy of the vendor kernel sources. Does this even exist? If not, the challenge is even bigger :)