paddywwoof
commented
5 years ago @carambathat I would say it's the other way round! The 'built in' GPU driver uses OpenGL ES 2.0 and that's what pi3d uses - via the broadcom drivers now referred to as 'legacy'. However to get software not originally designed for mobile platforms to work there has been a move to write a 'shell' driver that can interpret OpenGL code and either pass it on the GPU as ES2.0 code it can process or do some CPU processing. Unless the new driver is written very efficiently then I would expect it to be slower than 'pure' OpenGL ES code through the original driver.
There is an extra complication in the appearance of Mesa drivers (that I think are part of debian distributions) that can interpret GL code for the GLES hardware but not very well. They also scramble pi3d's fairly low level access to the GPU.
At one point I looked at making pi3d use SDL2 as a wrapper so it could be installed in a more standard way on different platforms. However I decided that the performance hit (plus the work of refactoring) wouldn't be worth it until the new GL driver for the RPi was finished and signed off. (I did make a Rust version of pi3d as a learning process for myself, which uses SDL2 and runs on windows, linux and RPi https://github.com/paddywwoof/rust_pi3d
I will post this reply to the forum as well
Paddy
The issue is summarized here:
https://www.raspberrypi.org/forums/viewtopic.php?t=230415
The answer from Raspberry team seems to be basically "Hey, it's the legacy program's issue"
Basically, neither of the 2 new Open GL options added to Raspbian Stretch is working with Pi3D:
G1 GL Full KMS (option 1) 128MB GPU memory split G2 GL Fake KMS (option 2), 128MB GPU memory split
The only option that is working is "Legacy" driver. Is it reasonably to assume that the Legacy driver is suboptimal Open GL solution?