as topics related to get the internal img gpu of the j7110 are spread across different threads lets maybe try to keep this thread here as a central documentation of efforts to get the gpu working beyond the images provided by starfive, i.e. best by building an own adjusted mesa, maybe own adjusted xorg server and other things required around this topic.
important note: gpu here means 3d like gles, opengl or vulkan and not video decoding/encoding as this is not done in the gpu but in a seperate component on the vf2 (like for most non pc hardware)
here are some forum threads more or less related to this topic i’m aware of so far (i’ll update the list if others are coming up in the thread):
a quick summary on how far i got so far: i have the gpu support now kind of working for my experimental debian sid image based on the pvr blobs, mesa and xorg binaries from the starfive debian images - and even that took me quite a while to get there … i plan to write this down a bit during the next days in case anyone else is interested.
i think i have a basic idea of how it works, but i’m not fully understanding it in detail yet … the kernel gpu driver loads the firmware into the gpu (which seems to be mips based) and starts it and then only the pvr library blobs from img are able to communicate to the gpu. to make it accessible from linux there seems to be some stub libraries (/usr/local/lib/libGLESv*) which i guess redirect the gles1 & 2 calls into the pvr blob libs - does this sound right and does anyone have an idea where the sources for those libs are? they do not seem to come from the special mesa build as gles1 & 2 is disabled for its build. then there is this special mesa build to provide some usual mesa style interface to it which does not seem to work for opengl (not sure about vulkan). opengl (2.1) i was able to get working by using gl4es (GitHub - ptitSeb/gl4es: GL4ES is a OpenGL 2.1/1.5 to GL ES 2.0/1.1 translation library, with support for Pandora, ODroid, OrangePI, CHIP, Raspberry PI, Android, Emscripten and AmigaOS4.) to get from gles2 to opengl. another option in the future might be zink in mesa to make opengl available on top of vulkan.
what i’m not really sure about yet is if the xorg build (in /usr/local of the starfive debian images as well) contains any further required hacks to make all this work - i guess so a bit, as i was not able to get a self build pvr adjusted mesa working with a stock debian xorg server (but i got it working with the starfive provided xorg binaries). it would be interesting if there are any sources/patches for that starfive xorg build available somewhere? maybe relevant is the fact that this xorg server is an older version (1.20.13) as the current debian one (1.20.13) - maybe this is required to work well together with the old (21.2.1) mesa version.
while playing around with all this i noticed that there are multiple versions of the gpu firmware and the binary blobs around and sadly all of them are named and versioned the same. the gpu kernel driver also changed slightly between kernel 2.10.4 and 2.11.5 resulting in a newer firmware version required (which is used in the 202303 starfive debian image). and as if all that would not be complicated enough already there seems to also be the requirement that kernel driver, gpu firmware and blob version all have to match each other to work
The sources for these libs are, as far as I’m aware, not public.
There are 2 binary files. rgx.sw.xxx and rgx.sh.xxx, the first is the firmware running in the microcontroller inside the GPU, the other is shader related (see the kernel log) not sure what it is for exactly.
You are right, the standard Mesa would not work with these driver and you need to use the lib provided with the binaries. I’m not sure why they have patches in Mesa.
Zink is, on the long term, probably the best option for OpenGL especially when Imagination opensource GPU driver will be merged in the kernel (some parts are already in Mesa)
As said in another topic, starfive have two version of the GPU driver (check on the github you’ll find both) it is likely that both set of binary you found are each of these, and yeah a mismatch is likely to not make it work properly.
I know the GPU for the VF2 is not (yet?) in the list of currently supported GPU for the opensource driver, but I wonder how hard it would be to add support for it, from what I saw it may not be that hard, the question is, what version of the binaries are needed.
i just had a quick look at the overlays and have no real know how about gentoo - am i right that you are using the default xorg server or does it have some vf2/img specific patches in it? which xorg server is it: the latest or some older to match the older mesa better?
Can you look at enabling OpenCL for your mesa build.
To enable the opencl use flag you need to remove it from
/var/db/repos/gentoo/profiles/arch/riscv/use.mask
When I try to merge your mesa it has a block on my system as I have OpenCL Installed and working on the GPU.
see
StarFive ~ # emerge --ask --verbose mesa::bingch
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 40.28 s.
[ebuild N ] media-libs/img-gpu-powervr-bin-1.17.6210866::bingch 60338 KiB
[ebuild UD ] media-libs/mesa-21.3.9::bingch [23.0.2-r1::gentoo] USE="X gles1 gles2 zstd -debug (-selinux) -test (-valgrind) -wayland (-d3d9%) (-llvm%*) (-lm-sensors%) (-opencl%*) (-osmesa%) (-proprietary-codecs%*) (-unwind%) (-vaapi%*) (-vdpau%) (-vulkan%*) (-vulkan-overlay%) (-xa%) (-zink%)" VIDEO_CARDS="imagination%* (-i915) (-i965) (-intel) -nouveau -r100% -r200% -radeon (-d3d12%) (-freedreno%) (-lima%) (-panfrost%) (-r300%) (-r600%) (-radeonsi%) (-v3d%) (-vc4%) (-virgl%) (-vivante%) (-vmware%)" 32040 KiB
[blocks B ] dev-libs/opencl-icd-loader ("dev-libs/opencl-icd-loader" is soft blocking media-libs/img-gpu-powervr-bin-1.17.6210866)
Total: 2 packages (1 downgrade, 1 new), Size of downloads: 92378 KiB
Conflict: 1 block (1 unsatisfied)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(dev-libs/opencl-icd-loader-2023.04.17:0/0::gentoo, installed) pulled in by
>=dev-libs/opencl-icd-loader-2023.02.06[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (>=dev-libs/opencl-icd-loader-2023.02.06) required by (virtual/opencl-3-r3:0/0::gentoo, installed) USE=""
(media-libs/img-gpu-powervr-bin-1.17.6210866:0/0::bingch, ebuild scheduled for merge) pulled in by
media-libs/img-gpu-powervr-bin required by (media-libs/mesa-21.3.9:0/0::bingch, ebuild scheduled for merge) USE="X gles1 gles2 zstd -debug (-selinux) -test (-valgrind) -wayland" VIDEO_CARDS="imagination (-i915) (-i965) (-intel) -nouveau -r100 -r200 -radeon"
For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages
StarFive ~ #
All packages is from gentoo upstream repo, the only 2 custom packages I have to create for StarFive are the patched mesa-21.3.9 and img-gpu-powervr-bin-1.17.6210866
At the moment xorg-server version from gentoo I am using is 21.1.8
