How are the promised GPU drivers from Imagination technologies going? I hear about them a lot and the proprietary ones have subpar API support (no desktop OpenGL 1/2??? Seriously?). I hear about them a lot on these forums but don’t have a status update.
1 Like
Well most mobile GPU and not just the PowerVR, if not nearly all of them do not support OpenGL but OpenGL ES. Have a look at the Raspberry Pi, It is OGLES, not OpenGL.
To quote elinux.org:
The Raspberry Pi contains a Broadcom VideoCore IV GPU providing OpenGL ES 1.1, OpenGL ES 2.0, hardware-accelerated OpenVG 1.1, Open EGL, OpenMAX and 1080p30 H.264 high-profile decode.
Raspberry Pi VideoCore APIs - eLinux.org
They don’t even support OpenGL ES 3.0 nor Vulkan as part of the standard drivers. The Vulkan driver they announced some time ago is not for all model (Pi4 only) and is a retrofit for a GPU that was not originally designed for the API.
As for the open source drivers, Imagination is in the process of mainlining the first kernel patches to support for now 3 of their Rogue GPUs. I know that the GPU in the VF2 (and also on the TH1520) is on their roadmap once these patches are mainlined.
Also if you really want OpenGL, as soon as the OSS driver will land, you’ll be able to use the vulkan shim Zink that provide OpenGL API to GPU providing the Vulkan API.
Edit: forgot to put the link to the latest patch-set RFC from Imagination:
[PATCH v5 00/17] Imagination Technologies PowerVR DRM driver (kernel.org)
2 Likes
I just think that a proper OpenGL 2.x driver would make the GPU on this board actually usable. The Raspberry Pi has it, for example, via the VC4 and V3D Mesa drivers. Is the open driver only going to add Vulkan? Most software doesn’t use it and Zink is slow compared to a native driver.
The hardware looks fantastic, the right software just needs to land. And that is 100% waiting on Imagination technologies. But they have been working on a clean slate big picture design, where they consider all their GPU designs/products and once they have finished with the three that they have selected to work on, I can imagine that everything else will be integrated very rapidly.
Yeah what good is it if you have a big beefy GPU that can’t run anything except maybe mobile games? I don’t mean to be off-putting here. It’s a very fine board and it’s a great intro to the RISC-V ecosystem, but I’m a strong proponent of quality, optimized driver access for 3d accelerators in SBCs. I really am excited for the open drivers and I hope that this driver work is also going towards basic desktop OpenGL so that maybe various programs like maybe Blender 2.79 could run.
1 Like
@Godzil As you noted, the Pi 4 has better OGL ES 3.1 and Vulkan support. There is no such thing as “the Pi”, as it’s all about the specific GPU/VPU.
Modern Rockchip SoCs also have OGL ES 3.1 support, and it seems Vulkan support is on the way.
1 Like
Just to highlight that the Imagination Technologies BXE-4-32 MC1 in the VF2 is OpenGL ES 3.x/2.0/1.1 + Extensions and not Open GL, they are different.
1 Like
(just as a side note, OpenGL 2.0 was released in September 2004, nearly 20 years ago. Today’s version of OpenGL is 4.6, and there is not that many GPU which actually support it)
OpenGL ES is actually pretty close to standard OpenGL, to the extend that modern OpenGL can be nearly mapped 1:1 with OGLES. OGLES is a somewhat cleaner version of OpenGL with most of the fixed pipeline stuff being removed.
An example, Godot 4 use OpenGL ES 3 internally for the “low end” bakcend, but on Desktop add a couple of line of code to make it work like OpenGL 3. The difference between them if done properly is honestly minor.
2 Likes
Doesn’t matter either way.
If vulkan works, zink will provide opengl over vulkan.
But we still need an open driver for Vulkan.
1 Like
True, but I’ll use the Pi as an example. Supporting desktop GL natively should be possible, and would provide greater compatibility with more software. If you want to expand the ecosystem to support legacy software such as Blender and the like.
I agree. However, desktop OpenGL is a current standard that would open up games and the like, and for this reason I support a native driver for the VF2. I don’t currently know enough about GPUs to develop drivers sadly but it’s something I’m insistent about.
if gles is there and desktop opengl is required, then 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. should help 
I tried it and it doesn’t work. Help with it maybe?
Haha meme number. On a serious note though oh damn I need to compile SDL!
mzs already posted the github issue - i got it working in the end, but its a long time ago meanwhile already, so i can’t tell much about the details anymore and it might not work in all cases (see mentioned github issue)
1 Like
Thanks. Also I like the forums here. I apologize for my insufferable demands for OpenGL support on this board. I really like the board and what it can do, it’s just that I want my visionfive 2 experience to eventually beat the raspberry pi graphics wise because the GPU is better.
2 Likes
I did the following:
user@starfive:~$ cd src
user@starfive:~/src$ git clone https://github.com/ptitSeb/gl4es
user@starfive:~/src$ cd gl4es
user@starfive:~/src/gl4es$ mkdir build
user@starfive:~/src/gl4es$ cd build/
user@starfive:~/src/gl4es/build$ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo; make -j 4
user@starfive:~/src/gl4es/build$ cd ../lib/
user@starfive:~/src/gl4es/lib$ ls -l
total 6104
-rwxr-xr-x 1 user user 6249584 Sep 5 17:31 libGL.so.1
user@starfive:~/src/gl4es/lib$ file libGL.so.1
libGL.so.1: ELF 64-bit LSB shared object, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), dynamically linked, BuildID[sha1]=d3981e4c9be2d1ed304baa69c9b40c03493fc8c8, with debug_info, not stripped
user@starfive:~/src/gl4es/lib$ echo $LD_LIBRARY_PATH
/usr/local/lib
user@starfive:~/src/gl4es/lib$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/home/user/src/gl4es/lib
user@starfive:~/src/gl4es/lib$ echo $LD_LIBRARY_PATH
/usr/local/lib:/home/user/src/gl4es/lib
user@starfive:~/src/gl4es/lib$ sudo apt install mesa-utils-bin -y
user@starfive:~/src$ git clone https://github.com/libsdl-org/SDL
user@starfive:~/src$ cd SDL
user@starfive:~/src/SDL$ git branch -r
user@starfive:~/src/SDL$ git checkout origin/SDL2
user@starfive:~/src/SDL$ cat INSTALL.txt
user@starfive:~/src/SDL$ ./configure; make -j4
user@starfive:~/src/SDL$ echo $LD_LIBRARY_PATH
/usr/local/lib:/home/user/src/gl4es/lib
user@starfive:~/src/SDL$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/home/user/src/SDL/build
user@starfive:~/src/SDL$ cd test
user@starfive:~/src/SDL/test$ ./configure
user@starfive:~/src/SDL/test$ make -j 4
user@starfive:~/src/SDL/test$ sudo apt install mesa-utils-bin -y
And then I was able to run “glxgears.riscv64-linux-gnu”, “glxheads.riscv64-linux-gnu” and “glxinfo.riscv64-linux-gnu” at my monitor refresh rate of 60 fps.
e.g.
And when I ran some of the SDL test programs they claimed that they were updating at 1000+ fps. But then I got distracted playing Quake 2 (Yamagi Quake II) on my VF2, and did not go any further.
5 Likes
Thank you for that. I already compiled the GL4ES library. I just need to compile sdl and stuff
1 Like