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 https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/issues/17#issuecomment-2481410588, 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. https://github.com/xerpi/vita-linux-loader/issues/4#issuecomment-2685732676

[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 :)

[xerpi]

Thanks! Unfortunately, the PSVita uses a fully custom SoC and OS, and its source code has not been released. However, the community has made significant progress in reverse engineering both the hardware and software of the PSVita. Our efforts are documented on the Vita Development Wiki.

Specifically, regarding the GPU, we've gathered some information on the GPU and the SGX instruction set (thanks to @motoharu-gosuto). Additionally, the Vita3K emulator includes a shader disassembler and recompiler/translator (to SPIR-V) for the GPU's ISA (USSE).

We also have the capability to decrypt the OS and user-space modules, allowing us to analyze them using reverse engineering tools such as IDA Pro or Ghidra.

[goldelico]

Wow, that is cool! There had been a project supported by FSF to reverse engineer the SGX instruction set approx. 10 to 15 years ago, but I think the server was shut down without leaving a copy... Another component that is needed to make a fully open system would be to have user-space libraries and firmware (kernel) that is installed on the SGX processor. For the kernel driver I had plans to merge all the variants (which mainly involve some #if SGX_REVISION, ERRATA, SOC_VERSION etc.) into a single driver and make everything differentiated by a device tree .compatible. The driver could then even present itself as the correct version in /proc/pvr. All instead of having a bunch of slightly different drivers which are individually compiled into separate kernel modules. But I never found enough time to at least draft something and the community behind this project isn't large...

[AyoubCoding21]

nice

[mirh]

I actually don't think any project ever went past the "document some stuff around" phase. @monocasa @embed-3d http://lkcl.net/powervr/sgx/ https://web.archive.org/web/20160409003957/http://powervr.gnu.org.ve/doku.php?id=opcodes https://web.archive.org/web/20160423202102/http://powervr.gnu.org.ve/doku.php?id=instructionencoding

...except maybe those odd SGX-based Intel igps, that with DRM_GMA500 and the xf86 driver Tungsten made should at least be able to get 2D accelerated (even if they used shortcuts).

[goldelico]

Ah, yes! I wasn't aware that it was web.archived... But you are right, this was just collecting a lot of documentation, but it appeared to be quite complex to write and test new code... AFAIR there was not even an attempt to write a "hello world from SGX" uKernel replacement :)

[xerpi]

I think @motoharu-gosuto reversed the USSE encoding format using this brute-forcing program https://github.com/motoharu-gosuto/psvgxp

[akku1139]

As you may know, I found the PowerVR SGX Device Tree binding in mainline. https://github.com/torvalds/linux/blob/097a6c336d0080725c626fda118ecfec448acd0f/Documentation/devicetree/bindings/gpu/img%2Cpowervr-sgx.yaml

edit: it was already known in this project

[AyoubCoding21]

How's the work going ?

Btw the vita-linux project was archived