# Does GameShell Actually Use FBTurbo? **URL:** \ **Category:** GameShell\ **Created:** [July 2, 2019, 8:34am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964 "2019-07-02T08:34:41Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Cecilectomy](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/cecilectomy/32/1358_2.png) [@Cecilectomy](https://forum.clockworkpi.com/u/Cecilectomy)\ **Post date:** [July 2, 2019, 8:34am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/1 "2019-07-02T08:34:41Z")
During some experimentation with OpenGL development on the GameShell, I did some investigation into the fbturbo and lima versions being used on the GameShell. While doing so I could not find any mention of fbturbo installed at all: `sudo find / -name fbturbo`, `dpkg -l | grep fbturbo`, and `sudo apt-cache search fbturbo` all yield nothing. Interstingly, what IS installed and being used, is fbdev, which as far as I can tell is NOT fbturbo, and that fbturbo is a drop in replacement for fbdev. [https://github.com/ssvb/xf86-video-fbturbo](https://github.com/ssvb/xf86-video-fbturbo) Am I missing something here? Does anyone know if it actually uses fbturbo or not? because if it’s not, from what I can tell, fbdev ONLY does 3d software rendering, but fbturbo actually makes use of the proprietary mali binary blobs that should be included in the kernel. I don’t want to waste my time pursuing this if it does actually already use fbturbo and I’m just not seeing it, but if it doesn’t, dear god if it works better than lima lets get fbturbo working! P.S. If it turns out that its using fbdev because fbturbo does not work on the hardware, then it should properly say fbdev and not fbturbo for the graphics driver in the settings, specifications, etc. ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 2, 2019, 9:14am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/2 "2019-07-02T09:14:58Z")
check inside _/usr/lib/xorg/modules/drivers_ you could recompile it yourself but will need also compile _libump_ > git clone --depth 1 [GitHub - linux-sunxi/libump: Unified Memory Provider userspace API source code needed for xf86-video-mali compilation](https://github.com/linux-sunxi/libump.git) > cd libump/ > autoreconf -i > ./configure > make -j4 > sudo make install > git clone --depth 1 [GitHub - ssvb/xf86-video-fbturbo: Xorg DDX driver for ARM devices (Allwinner, RPi and others)](https://github.com/ssvb/xf86-video-fbturbo.git) > cd xf86-video-fbturbo/ > ./autogen.sh > make -j4 > sudo make install > cd /usr/lib/xorg/modules/drivers/ > sudo mv fbturbo\_drv.so fbturbo\_drv.so.old > sudo mv fbturbo\_drv.la fbturbo\_drv.la.old > sudo cp /usr/local/lib/xorg/modules/drivers/fbturbo\* . ---
**Author:** ![Cecilectomy](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/cecilectomy/32/1358_2.png) [@Cecilectomy](https://forum.clockworkpi.com/u/Cecilectomy)\ **Post date:** [July 2, 2019, 10:30am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/3 "2019-07-02T10:30:36Z")
Ah, I know why I wasn’t finding it. my find command should have been `sudo find / -name *fbturbo*`, that picks it up, and shows exactly where you specified. Is the GameShell ACTUALLY utilizing it though? **According to lsof when using lima:** ``` cpi@clockworkpi:~$ sudo lsof +D /usr/lib/xorg/modules/drivers/ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Xorg 921 cpi mem REG 179,2 55900 137839 /usr/lib/xorg/modules/drivers/modesetting_drv.so ``` **And when “using fbturbo”:** ``` cpi@clockworkpi:~$ sudo lsof +D /usr/lib/xorg/modules/drivers/ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Xorg 921 cpi mem REG 179,2 18312 137843 /usr/lib/xorg/modules/drivers/fbdev_drv.so ``` That doesn’t look like its using fbturbo at all, it is still using fbdev. Looking through /home/cpi/.local/share/xorg/Xorg.0.log I found that it never actually loads the .xorg.conf (or .xorg\_lima.conf when for that matter when set to use lima) that specifies fbturbo `[741.718] (EE) Unable to locate/open config file: "~/launcher/.xorg.conf"` If you change ~/launcher/.cpirc to use `/home/cpi/launcher/.xorg.conf` instead of `~/launcher/.xorg.conf` (and for .xorg\_lima.conf as well) it actually DOES load the conf and then lsof reports that fbturbo\_drv.so is open! ``` cpi@clockworkpi:~$ sudo lsof +D /usr/lib/xorg/modules/drivers/ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Xorg 924 cpi mem REG 179,2 327756 137838 /usr/lib/xorg/modules/drivers/fbturbo_drv.so ``` Have we never actually been using fbturbo!? ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 2, 2019, 11:05am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/4 "2019-07-02T11:05:33Z")
awesome %) lima included in the clockwork image have some function unimplemented, the one now included in mainline kernel must be much more advanced with kernel & full gfx stack upgraded there was also 5~10 fps more in glxgear using fbdev ---
**Author:** ![Cecilectomy](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/cecilectomy/32/1358_2.png) [@Cecilectomy](https://forum.clockworkpi.com/u/Cecilectomy)\ **Post date:** [July 3, 2019, 11:25pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/5 "2019-07-03T23:25:55Z")
So it does not appear that fbturbo is really adding any benefits over the default fbdev… that I can tell. If it is using it correctly and is utilizing the mali kernel module, it should be providing better performance over fbdev. I’m going to do a little more digging, but it looks like the ClockworkOS’s linux kernel does not have the Mali module included, which would explain the similar performance between fbturbo and fbdev, instead of an improvement. Additionally, from what I currently understand about the lima driver, is that lima is a full driver for mali based gpu’s, which is why it add’s a lot of performance improvement over fbdev/turbo, and doesn’t actually need the proprietary mali blob. ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 4, 2019, 4:26pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/6 "2019-07-04T16:26:14Z")
clockwork patch for kernel 4.20 seem have mali enabled [https://raw.githubusercontent.com/clockworkpi/Kernel/master/CPI3\_linux\_4.20/cpi3\_linux\_4\_20\_1902.patch](https://raw.githubusercontent.com/clockworkpi/Kernel/master/CPI3_linux_4.20/cpi3_linux_4_20_1902.patch) > ``` > +CONFIG_DRM_MALI_DISPLAY=y > > ``` [https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/](https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/) blobs could be found here \> [GitHub - bootlin/mali-blobs: Mali OpenGL ES userspace libraries for Allwinner SoCs](https://github.com/bootlin/mali-blobs) [GitHub - linux-sunxi/sunxi-mali-proprietary: Sunxi Mali-400 proprietary support libraries.](https://github.com/linux-sunxi/sunxi-mali-proprietary) * * * you could also try my own kernel, with latest lima (& mali) [http://gs.dread.fr/kernel/latest/](http://gs.dread.fr/kernel/latest/) (take care there is a sound driver bug, constant 60db amplification) (you may also wanna upgrade mesa as latest one support lima, a compiled release is here [http://gs.dread.fr/kernel/kernel.gfx.stack/](http://gs.dread.fr/kernel/kernel.gfx.stack/) xorg is also compiled to latest one, and fbturbo recompiled for latest xorg i directly installed all on my gs after compile (on os 1.0) so i not tested these tar, duckyvirus reported some trouble with them, you may have more luck ---
**Author:** ![Cecilectomy](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/cecilectomy/32/1358_2.png) [@Cecilectomy](https://forum.clockworkpi.com/u/Cecilectomy)\ **Post date:** [July 4, 2019, 8:34pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/7 "2019-07-04T20:34:34Z")
Yup, I remembered and found @duckyvirus’s thread and the next thing I’m going to be doing is getting a custom kernel working. @guu, is there any way we can get more detailed instructions on the custom kernel and image builds? It would also be nice if we could get unstable nightly builds of the ClockworkOS img for testing, which also may speed up the time between OS image updates. Let us know thoughts on this. ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 4, 2019, 10:47pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/8 "2019-07-04T22:47:01Z")
++++1 and more generally let the community be a full part of future releases this may not what you wanted, but you actually lack a lot about communication, some peoples around try things going further, a bit of help could be nice. ---
**Author:** ![guu](https://avatars.discourse-cdn.com/v4/letter/g/7ab992/32.png) [@guu](https://forum.clockworkpi.com/u/guu)\ **Post date:** [July 5, 2019, 3:08am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/9 "2019-07-05T03:08:44Z")
haha I wish I can But I am not the os image maker ---
**Author:** ![Cecilectomy](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/cecilectomy/32/1358_2.png) [@Cecilectomy](https://forum.clockworkpi.com/u/Cecilectomy)\ **Post date:** [July 5, 2019, 3:26am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/10 "2019-07-05T03:26:34Z")
I’ve got a 4.20 kernel build compiled and running on my GameShell. @r043v I’ll be trying out building your 5.x mainline kernel next to see how that goes. @guu It doesn’t specifically have to be you lol, you just happen to be the most active when it comes to dev, and seem to manage the git repositories. It would / could be whoever manages the kernel patching and building, and putting the final OS .img together. It would also be beneficial to have details on the device tree bindings / blobs. ---
**Author:** ![Cecilectomy](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/cecilectomy/32/1358_2.png) [@Cecilectomy](https://forum.clockworkpi.com/u/Cecilectomy)\ **Post date:** [July 5, 2019, 7:39pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/11 "2019-07-05T19:39:16Z")
@r043v I was not able to get your kernel working entirely either. If I install just the kernel, it boots fine, but the launcher fails due to bluetooth service issues (probably due to the dtb being wrong, as it works for other kernels). If I try to use your up to date graphics stack, I just get dropped to a command line due to all sorts of dependency issues. I’ve tried resolving them one after another, but that seemed like a waste of time to me. I’ve moved on to just trying to make the 4.20 kernel work with fbturbo and mali kernel driver. It appears that even though CONFIG\_DRM\_MALI\_DISPLAY=y exists in the config, all that does is add mali to the device tree? There isn’t actually any mali.ko kernel driver even when run make modiles\_prepare or make modules\_install, so I don’t think any of the current Clockwork OS images actually have the proprietary mali driver available? I tried to compile the mali kernel space driver (mali.ko) and was successful, but cannot get it to load currently (sudo modprobe mali). dmesg gives: ``` [53.899067] WARNING: CPU: 1 PID: 1381 at drivers/reset/core.c:419 __reset_control_get_internal+0xc0/0xe0 [53.908601] Modules linked in: mali(O+) [53.912472] CPU: 1 PID: 1381 Comm: modprobe Tainted: G W O 4.20.9-clockworkpi-cpi3 #1 [53.921419] Hardware name: Allwinner sun8i Family [53.926146] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [53.933911] [] (show_stack) from [] (dump_stack+0x84/0x98) [53.941156] [] (dump_stack) from [] (__warn+0xfc/0x114) [53.948120] [] (__warn) from [] (warn_slowpath_null+0x40/0x48) [53.955686] [] (warn_slowpath_null) from [] (__reset_control_get_internal+0xc0/0xe0) [53.965159] [] (__reset_control_get_internal) from [] (__of_reset_control_get+0x174/0x1a0) [53.975383] [] (__of_reset_control_get) from [] (mali_platform_device_register+0x134/0x89c [mali]) [53.986287] [] (mali_platform_device_register [mali]) from [] (init_module+0x8/0x70 [mali]) [53.996470] [] (init_module [mali]) from [] (do_one_initcall+0x54/0x194) [54.004906] [] (do_one_initcall) from [] (do_init_module+0x60/0x364) [54.012991] [] (do_init_module) from [] (load_module+0x1df8/0x2210) [54.020989] [] (load_module) from [] (sys_finit_module+0xc8/0xd8) [54.028811] [] (sys_finit_module) from [] (ret_fast_syscall+0x0/0x54) [54.036975] Exception stack(0xec9a3fa8 to 0xec9a3ff0) [54.042024] 3fa0: 00432e20 00432180 00000003 0041eadc 00000000 0041f1b0 [54.050193] 3fc0: 00432e20 00432180 21c38f00 0000017b 00040000 00000000 00000000 00432e20 [54.058377] 3fe0: bed083c8 bed083b8 004163af b6eb91c2 ``` I may try a bit more before giving up on this. I’m just super curious to see if we could get fbturbo working properly with mali, as it should be more than just software rendering. ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 5, 2019, 8:52pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/12 "2019-07-05T20:52:47Z")
yes my patch on the kernel may not include bluetooth, i patched the initial patch, not 4.20 one, i’ll will check it when i’ll get a bit more time dts was need multiples changes due to some pin rename, on my system latest dtb seem hang on boot due to wifi graphic stack was need additional packages for compile, but worked fine without other needs once installed i’ll also check them, i need time isn’t mali referenced inside buildin file of the module directory ? all of this is a bit messy :S hard to setup ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 8, 2019, 7:22pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/13 "2019-07-08T19:22:36Z")
here is dmesg & Xorg log for os 0.4 with lima enabled [http://gs.dread.fr/4/](http://gs.dread.fr/4/) ---
**Author:** ![Cecilectomy](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/cecilectomy/32/1358_2.png) [@Cecilectomy](https://forum.clockworkpi.com/u/Cecilectomy)\ **Post date:** [July 8, 2019, 8:38pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/14 "2019-07-08T20:38:32Z")
I’m going to be submitting a pull request to fix the ~/launcher/.cpirc so it loads the .xorg.conf and .xorg\_lima.conf correctly, but even with that fbturbo still does not seem to be making use of mali though, same performance as just using fbdev. I looked in the modules.builtin and you are correct, it does appear to have a mali module builtin but it is referenced as “mali-dp.ko”, not “mali.ko” which is what it is called when you build the mali kernel space module as an external module. I also noticed that `cat /proc/devices` does not contain a reference to mali, which it should if it exists in the device tree and the mali kernel space module was loaded (maybe mali-dp is not the correct module). I noticed this when I tried to build the mali **userspace** modules ([http://linux-sunxi.org/Mali\_binary\_driver#Installing\_the\_Mali\_userspace\_driver](http://linux-sunxi.org/Mali_binary_driver#Installing_the_Mali_userspace_driver)), the /dev/mali node does not exist either. This is getting extroadinarily frustraing lol. @yong or @guu will there be a new patch file, etc. added to [https://github.com/clockworkpi/Kernel](https://github.com/clockworkpi/Kernel) soon? ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 8, 2019, 11:54pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/15 "2019-07-08T23:54:13Z")
lima xorg conf file just refer modesetting, so kms, as it’s the default it may be ok anyway ? i recompiled mesa / xorg / fbdev ``` cpi@clockworkpi:~$ export DISPLAY=:0.0 cpi@clockworkpi:~/dev/glmark2$ glxgears -info GL_RENDERER = Mali400 GL_VERSION = 2.1 Mesa 18.3.0 (git-00d67e27d9) GL_VENDOR = lima GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color ... VisualID 238, 0xee error: lima_blit not implemented 302 frames in 5.0 seconds = 60.361 FPS 299 frames in 5.0 seconds = 59.793 FPS ^C cpi@clockworkpi:~$ es2gears EGL_VERSION = 1.4 error: lima_blit not implemented vertex shader info: fragment shader info: info: 302 frames in 5.0 seconds = 60.364 FPS 299 frames in 5.0 seconds = 59.788 FPS ^C cpi@clockworkpi:~$ glxinfo -B name of display: :0.0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: lima (0x13b5) Device: Mali400 (0xffffffff) Version: 18.3.0 Accelerated: yes Video memory: 0MB Unified memory: yes Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL vendor string: lima OpenGL renderer string: Mali400 OpenGL version string: 2.1 Mesa 18.3.0 (git-00d67e27d9) OpenGL shading language version string: 1.20 OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.3.0 (git-00d67e27d9) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 ``` software glxgear / es2gears go 105 ~110 fps on my previous tests but yet as hardware acceleration work on classic glxgears if i do : ``` cpi@clockworkpi:~/dev/glmark2$ MESA_GL_VERSION_OVERRIDE=4.3 glxgears -info GL_RENDERER = Mali400 GL_VERSION = 4.3 (Compatibility Profile) Mesa 18.3.0 (git-00d67e27d9) GL_VENDOR = lima GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra ... VisualID 238, 0xee error: lima_blit not implemented 303 frames in 5.0 seconds = 60.388 FPS 300 frames in 5.0 seconds = 59.820 FPS ``` we could request fresh opengl so much more compatibility like in mainline gzdoom who dropped support of gl2 for now glmark2 crash : ``` cpi@clockworkpi:~/dev/glmark2$ sudo glmark2-es2-drm -s 320x240 --validate Ignoring custom size 320x240 for validation. Using 800x600. ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: lima GL_RENDERER: Mali400 GL_VERSION: OpenGL ES 2.0 Mesa 18.3.0 (git-00d67e27d9) ======================================================= [build] use-vbo=false:Error: Failed to set crtc: -13 Validation: Failure [build] use-vbo=true:Error: Failed to set crtc: -13 Validation: Failure [texture] texture-filter=nearest:Error: Failed to set crtc: -13 Validation: Failure [texture] texture-filter=linear:Error: Failed to set crtc: -13 Validation: Failure error: lima_blit not implemented error: lima_blit not implemented error: lima_blit not implemented error: lima_blit not implemented error: lima_blit not implemented error: lima_blit not implemented error: lima_blit not implemented error: lima_blit not implemented error: lima_blit not implemented [texture] texture-filter=mipmap:Segmentation fault ``` ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 8, 2019, 11:58pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/16 "2019-07-08T23:58:50Z")
os 0.4 does not contain modules folder for current kernel mali-dp seem refer to mali display processor, the mali kernel parameter we spoken about last time refer to this, as this page [https://en.wikipedia.org/wiki/Mali\_(GPU)](https://en.wikipedia.org/wiki/Mali_(GPU)) it seem not related to mali 400 … yes got last patch will be great \o/ ---
**Author:** ![MrWildBunnycat](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/mrwildbunnycat/32/1620_2.png) [@MrWildBunnycat](https://forum.clockworkpi.com/u/MrWildBunnycat)\ **Post date:** [July 9, 2019, 12:07am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/17 "2019-07-09T00:07:12Z")
Wait, does 0.4 still use the outdated Lima driver or the one in the mainline kernel? ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 9, 2019, 12:10am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/18 "2019-07-09T00:10:36Z")
don’t know, i need try my compiled 5.2, hope it will work with their dtb ---
**Author:** ![r043v](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/r043v/32/672_2.png) [@r043v](https://forum.clockworkpi.com/u/r043v)\ **Post date:** [July 9, 2019, 2:06am UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/19 "2019-07-09T02:06:54Z")
as you said my kernel was made crash launcher cause of bluetooth, i just enable it & recompile can be found here \> [http://gs.dread.fr/kernel/latest/](http://gs.dread.fr/kernel/latest/) as with last image i cannot use hw acceleration ``` [19.250] (II) AIGLX: Screen 0 is not DRI2 capable [20.856] (II) IGLX: Loaded and initialized swrast [20.856] (II) GLX: Initialized DRISWRAST GL provider for screen 0 ``` checked 4.20 patch & 0.4 xorg log, enable some things like drm\_sun4i but no luck for now i’ll retry tomorow, it’s 4am Zzz ---
**Author:** ![adcockm](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/adcockm/32/1664_2.png) [@adcockm](https://forum.clockworkpi.com/u/adcockm)\ **Post date:** [January 30, 2020, 1:36pm UTC](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964/20 "2020-01-30T13:36:54Z")
Sorry to reawaken an old thread, but after doing some testing with ptitSeb on the latest box86 fixes, he pointed out that my Gameshell seems to be running software OpenGL instead of using Lima, based on what it was producing in the logs. But I have it set to Lima, so I’m not sure what’s going on. I was trying to find the old thread I remember where someone mentioned (perhaps you?) how to check in the system for whether Lima is active (not just in the launcher). Anyhow, I went ahead and ran glxgears and came up with this: > cpi@clockworkpi:~$ DISPLAY=:0 glxgears -info > GL\_RENDERER = llvmpipe (LLVM 7.0, 128 bits) > GL\_VERSION = 3.1 Mesa 18.3.6 > GL\_VENDOR = VMware, Inc. > GL\_EXTENSIONS = GL\_ARB\_multisample GL\_EXT\_abgr GL\_EXT\_bgra GL\_EXT\_blend\_color GL\_EXT\_blend\_minmax GL\_EXT\_blend\_subtract GL\_EXT\_copy\_texture GL\_EXT\_subtexture GL\_EXT\_texture\_object GL\_EXT\_vertex\_array GL\_EXT\_compiled\_vertex\_array GL\_EXT\_texture GL\_EXT\_texture3D GL\_IBM\_rasterpos\_clip GL\_ARB\_point\_parameters GL\_EXT\_draw\_range\_elements GL\_EXT\_packed\_pixels GL\_EXT\_point\_parameters GL\_EXT\_rescale\_normal GL\_EXT\_separate\_specular\_color GL\_EXT\_texture\_edge\_clamp GL\_SGIS\_generate\_mipmap GL\_SGIS\_texture\_border\_clamp GL\_SGIS\_texture\_edge\_clamp GL\_SGIS\_texture\_lod GL\_ARB\_framebuffer\_sRGB GL\_ARB\_multitexture GL\_EXT\_framebuffer\_sRGB GL\_IBM\_multimode\_draw\_arrays GL\_IBM\_texture\_mirrored\_repeat GL\_ARB\_texture\_cube\_map GL\_ARB\_texture\_env\_add GL\_ARB\_transpose\_matrix GL\_EXT\_blend\_func\_separate GL\_EXT\_fog\_coord GL\_EXT\_multi\_draw\_arrays GL\_EXT\_secondary\_color GL\_EXT\_texture\_env\_add GL\_EXT\_texture\_lod\_bias GL\_INGR\_blend\_func\_separate GL\_NV\_blend\_square GL\_NV\_light\_max\_exponent GL\_NV\_texgen\_reflection GL\_NV\_texture\_env\_combine4 GL\_S3\_s3tc GL\_SUN\_multi\_draw\_arrays GL\_ARB\_texture\_border\_clamp GL\_ARB\_texture\_compression GL\_EXT\_framebuffer\_object GL\_EXT\_texture\_compression\_s3tc GL\_EXT\_texture\_env\_combine GL\_EXT\_texture\_env\_dot3 GL\_MESA\_window\_pos GL\_NV\_packed\_depth\_stencil GL\_NV\_texture\_rectangle GL\_ARB\_depth\_texture GL\_ARB\_occlusion\_query GL\_ARB\_shadow GL\_ARB\_texture\_env\_combine GL\_ARB\_texture\_env\_crossbar GL\_ARB\_texture\_env\_dot3 GL\_ARB\_texture\_mirrored\_repeat GL\_ARB\_window\_pos GL\_ATI\_fragment\_shader GL\_EXT\_stencil\_two\_side GL\_EXT\_texture\_cube\_map GL\_NV\_depth\_clamp GL\_NV\_fog\_distance GL\_APPLE\_packed\_pixels GL\_ARB\_draw\_buffers GL\_ARB\_fragment\_program GL\_ARB\_fragment\_shader GL\_ARB\_shader\_objects GL\_ARB\_vertex\_program GL\_ARB\_vertex\_shader GL\_ATI\_draw\_buffers GL\_ATI\_texture\_env\_combine3 GL\_ATI\_texture\_float GL\_EXT\_shadow\_funcs GL\_EXT\_stencil\_wrap GL\_MESA\_pack\_invert GL\_MESA\_ycbcr\_texture GL\_NV\_primitive\_restart GL\_ARB\_depth\_clamp GL\_ARB\_fragment\_program\_shadow GL\_ARB\_half\_float\_pixel GL\_ARB\_occlusion\_query2 GL\_ARB\_point\_sprite GL\_ARB\_shading\_language\_100 GL\_ARB\_sync GL\_ARB\_texture\_non\_power\_of\_two GL\_ARB\_vertex\_buffer\_object GL\_ATI\_blend\_equation\_separate GL\_EXT\_blend\_equation\_separate GL\_OES\_read\_format GL\_ARB\_color\_buffer\_float GL\_ARB\_pixel\_buffer\_object GL\_ARB\_texture\_compression\_rgtc GL\_ARB\_texture\_float GL\_ARB\_texture\_rectangle GL\_ATI\_texture\_compression\_3dc GL\_EXT\_packed\_float GL\_EXT\_pixel\_buffer\_object GL\_EXT\_texture\_compression\_dxt1 GL\_EXT\_texture\_compression\_rgtc GL\_EXT\_texture\_mirror\_clamp GL\_EXT\_texture\_rectangle GL\_EXT\_texture\_sRGB GL\_EXT\_texture\_shared\_exponent GL\_ARB\_framebuffer\_object GL\_EXT\_framebuffer\_blit GL\_EXT\_framebuffer\_multisample GL\_EXT\_packed\_depth\_stencil GL\_ARB\_vertex\_array\_object GL\_ATI\_separate\_stencil GL\_ATI\_texture\_mirror\_once GL\_EXT\_draw\_buffers2 GL\_EXT\_draw\_instanced GL\_EXT\_gpu\_program\_parameters GL\_EXT\_texture\_array GL\_EXT\_texture\_compression\_latc GL\_EXT\_texture\_integer GL\_EXT\_texture\_sRGB\_decode GL\_EXT\_timer\_query GL\_OES\_EGL\_image GL\_ARB\_copy\_buffer GL\_ARB\_depth\_buffer\_float GL\_ARB\_draw\_instanced GL\_ARB\_half\_float\_vertex GL\_ARB\_instanced\_arrays GL\_ARB\_map\_buffer\_range GL\_ARB\_texture\_buffer\_object GL\_ARB\_texture\_rg GL\_ARB\_texture\_swizzle GL\_ARB\_vertex\_array\_bgra GL\_EXT\_texture\_swizzle GL\_EXT\_vertex\_array\_bgra GL\_NV\_conditional\_render GL\_AMD\_conservative\_depth GL\_AMD\_draw\_buffers\_blend GL\_AMD\_seamless\_cubemap\_per\_texture GL\_AMD\_shader\_stencil\_export GL\_ARB\_ES2\_compatibility GL\_ARB\_blend\_func\_extended GL\_ARB\_compatibility GL\_ARB\_debug\_output GL\_ARB\_draw\_buffers\_blend GL\_ARB\_draw\_elements\_base\_vertex GL\_ARB\_explicit\_attrib\_location GL\_ARB\_fragment\_coord\_conventions GL\_ARB\_provoking\_vertex GL\_ARB\_sampler\_objects GL\_ARB\_seamless\_cube\_map GL\_ARB\_shader\_stencil\_export GL\_ARB\_shader\_texture\_lod GL\_ARB\_texture\_buffer\_object\_rgb32 GL\_ARB\_texture\_cube\_map\_array GL\_ARB\_texture\_gather GL\_ARB\_texture\_multisample GL\_ARB\_texture\_query\_lod GL\_ARB\_texture\_rgb10\_a2ui GL\_ARB\_uniform\_buffer\_object GL\_ARB\_vertex\_type\_2\_10\_10\_10\_rev GL\_EXT\_provoking\_vertex GL\_EXT\_texture\_snorm GL\_MESA\_texture\_signed\_rgba GL\_ARB\_draw\_indirect GL\_ARB\_get\_program\_binary GL\_ARB\_robustness GL\_ARB\_separate\_shader\_objects GL\_ARB\_shader\_bit\_encoding GL\_ARB\_shader\_subroutine GL\_ARB\_texture\_compression\_bptc GL\_ARB\_timer\_query GL\_ARB\_transform\_feedback2 GL\_ARB\_transform\_feedback3 GL\_ARB\_viewport\_array GL\_AMD\_multi\_draw\_indirect GL\_ANGLE\_texture\_compression\_dxt3 GL\_ANGLE\_texture\_compression\_dxt5 GL\_ARB\_base\_instance GL\_ARB\_compressed\_texture\_pixel\_storage GL\_ARB\_conservative\_depth GL\_ARB\_internalformat\_query GL\_ARB\_map\_buffer\_alignment GL\_ARB\_shading\_language\_420pack GL\_ARB\_shading\_language\_packing GL\_ARB\_texture\_storage GL\_ARB\_transform\_feedback\_instanced GL\_EXT\_framebuffer\_multisample\_blit\_scaled GL\_EXT\_transform\_feedback GL\_AMD\_shader\_trinary\_minmax GL\_ARB\_ES3\_compatibility GL\_ARB\_arrays\_of\_arrays GL\_ARB\_clear\_buffer\_object GL\_ARB\_copy\_image GL\_ARB\_explicit\_uniform\_location GL\_ARB\_fragment\_layer\_viewport GL\_ARB\_invalidate\_subdata GL\_ARB\_multi\_draw\_indirect GL\_ARB\_program\_interface\_query GL\_ARB\_stencil\_texturing GL\_ARB\_texture\_buffer\_range GL\_ARB\_texture\_query\_levels GL\_ARB\_texture\_storage\_multisample GL\_ARB\_texture\_view GL\_ARB\_vertex\_attrib\_binding GL\_KHR\_debug GL\_KHR\_texture\_compression\_astc\_ldr GL\_ARB\_buffer\_storage GL\_ARB\_clear\_texture GL\_ARB\_enhanced\_layouts GL\_ARB\_internalformat\_query2 GL\_ARB\_multi\_bind GL\_ARB\_seamless\_cubemap\_per\_texture GL\_ARB\_texture\_mirror\_clamp\_to\_edge GL\_ARB\_texture\_stencil8 GL\_ARB\_vertex\_type\_10f\_11f\_11f\_rev GL\_EXT\_shader\_integer\_mix GL\_ARB\_clip\_control GL\_ARB\_conditional\_render\_inverted GL\_ARB\_cull\_distance GL\_ARB\_direct\_state\_access GL\_ARB\_get\_texture\_sub\_image GL\_ARB\_pipeline\_statistics\_query GL\_ARB\_transform\_feedback\_overflow\_query GL\_EXT\_polygon\_offset\_clamp GL\_KHR\_context\_flush\_control GL\_KHR\_no\_error GL\_KHR\_texture\_compression\_astc\_sliced\_3d GL\_MESA\_shader\_integer\_functions GL\_ARB\_polygon\_offset\_clamp > VisualID 696, 0x2b8 > 306 frames in 5.0 seconds = 61.178 FPS > 502 frames in 5.0 seconds = 100.210 FPS > 501 frames in 5.0 seconds = 100.034 FPS > 499 frames in 5.0 seconds = 99.753 FPS > 496 frames in 5.0 seconds = 99.027 FPS > 496 frames in 5.0 seconds = 99.140 FPS The llvmpipe thing is what ptitSeb saw in the logs and why he suggested it was not using Lima after all. This is all on 0.5 official. I’m wondering if I somehow accidentally clobbered my GL drivers in some of my testing and experimental builds? I think it’s unlikely but I’m wondering what others might get if they run `glxgears -info` @javelinface, care to give that a try and share your results? Maybe it is using Lima and just reports it weird. But I’d like to be more certain. Thanks! [Next page](https://forum.clockworkpi.com/t/does-gameshell-actually-use-fbturbo/3964.md?page=2)