[PATCH v3 00/17] Imagination Technologies PowerVR DRM driver

[H. Nikolaus Schaller]

Hi Frank,
I have added Merlijn who is doing a lot with PVRSGX for Maemo-Leste and the
phone-devel list since most SoC we find using a PVRSGX are smartphone processors.

> Am 26.06.2023 um 15:45 schrieb Frank Binns <Frank.Binns at imgtec.com>:
> 
> Hi Nikolaus,
> 
>> 
>> Some questions to the author of the new driver:
>> - are there plans to support SGX5 (the predecessor of Rogue6)?
> 
> We don't currently have any plans to support SGX. Our main focus is currently on
> Rogue and then we'll move onto Volcanic.

Okay, that's completely understandable from a commercial perspective.

> 
>> - will this be able to run the existing firmware and user-space code of pvrsrvkm?
> 
> I'm afraid not. The interface for existing firmware and userspace code were
> designed with different requirements in mind and don't cater to the kernel's
> strict compatibility guarantees. As such, the uapi for this new driver is
> very different to pvrsrvkm's, although naturally there are similarities:
> https://gitlab.freedesktop.org/sarah-walker-imgtec/powervr/-/blob/dev/v3/include/uapi/drm/pvr_drm.h

This makes sense. So the new Rogue/Volcanic and the older PVRSGX drivers should
be able to coexist (at least in source code as there is no hardware having both).

> We've also worked with our firmware team to make changes to the firmware
> interface to better support this new driver. Specifically, parts of the firmware
> interface are no longer conditional on the GPU feature set / hardware
> workarounds, meaning we now have a single interface which can work across all
> existing Rogue GPUs, which makes things a lot easier for this new kernel driver.

That is what I have dreamed of for SGX as well.

We could have replaced all the #if for specific versions and errata by some code
to runtime check with the device tree for the specific SGX version.

But this was never done because it is complex, difficult to automate and our means
for testing things are limited. And we could not decide which DDK version we
should build on as there is no common denominator for all SoC.

> 
>> - or will it have new firmware and user-space code for these older chips?
>> - or will there be open user-space code for SGX (and Rogue)?
> 
> We're using the same Rogue firmware as our closed source driver, just with
> modifications to the interface to cater for this new kernel driver. In terms of

Ok. Well, it was to be expected that SGX and Rogue firmware are quite different.

> userspace, we already have a Vulkan driver upstreamed to Mesa:
> https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/imagination/vulkan

Nice!

> 
> and will be working to enable GLES support via Mesa's Zink GL(ES)-to-Vulkan
> translation layer. This naturally limits support to Series 6 onwards, as
> anything older isn't capable of supporting Vulkan.

I see.

> 
>> 
>>> Specifically I would ask that the DT bindings include all old and new PowerVR
>>> hardware in one go, unless they have very specific hardware definition needs,
>>> which I doubt.
>> 
>> Our current bindings for all SoC with a SGX5 GPU inside and which have at least
>> some official Linux support are here:
>> 
>> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/omap-pvr-soc-glue-v8/Documentation/devicetree/bindings/gpu/img%2Cpvrsgx.yaml
>> 
>> There was an attempt to upstream at least this plus glue code (i.e. device tree
>> sources) some years ago but there was no consensus about the number and names of
>> clocks that should be included in such a bindings document.
> 
> I've taken a look and your bindings look very similar to the ones we've come up
> with. If you decide to attempt to upstream these again, please feel free to CC
> me, Sarah and Donald (all on this email chain) so we can provide some feedback.

That is good!

It would be a good moment to give it another try as we can have even more
reviewers than before...

> 
>> 
>>> Also I think they could use your help to get the proper firmware for the older
>>> hardware licensed properly from Imagination and included into linux-firmware
>>> so they do not need to ship files on the side.
>> 
>> Indeed, this and some "universal" user-space code would help a lot. Currently
>> we have collected a lot of binaries for several architectures (e.g. Intel, OMAP, JZ4780),
>> but all from different DDK versions and very different assumptions about system
>> library versions.
> 
> The way the SGX driver was designed means that it has to be built for a specific
> GPU, the version of the firmware, userspace driver(s) & kernel driver have to
> exactly match and the build configuration has to match as well. Essentially, we
> don't have "universal" userspace code ourselves. With our focus being on Rogue
> and beyond, we don't currently have any plans to work on this.

Hm. This makes me wonder if it could be possible to open source the SGX code
since it is a different architecture than Rogue, is no longer your focus and
AFAIK the last SoC with SGX hit market almost a decade ago. This would enable
the community to make driver, firmware and user-space more generic (and more
compatible to modern distributions e.g. libc and other versions).

Perhaps others interested in PVRSGX can chime in.

> 
> Thanks
> Frank

Thanks as well,
Nikolaus