Enable 3d acceleration

From www.ReeltoReel.nl Wiki
Revision as of 12:38, 31 July 2019 by Pvdm (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Re: How to turn on OpenGL on RPi 3B (Solved) Quote Sun Oct 14, 2018 11:04 pm

https://www.reddit.com/r/openSUSE/comme ... _question/ OP sdoconnell "3 months ago", 2018-07-xx. He found the solution in https://www.suse.com/documentation/suse ... rry-pi.pdf the SuSE documention for SLES-12 SP3 on Raspberry Pi (PDF).

I did the following procedure with no problems on two different Raspberry Pi 3B's:

1. Since Eric Anholt's accelerated vc4 driver is "experimental", SuSE ships it with 3D acceleration suppressed. Edit /etc/X11/xorg.conf.d/20-kms.conf and comment out Option "AccelMethod" "none".

2. Install package Mesa-dri-vc4 which provides the direct rendering module for the X-Server.

3. In /boot/efi/extraconfig.txt you need dtoverlay=vc4-kms-v3d or dtoverlay=vc4-fkms-v3d ("fake" KMS). Other forum posts suggest that the latter one works better for streaming video, so I'm using that one.

4. The kernel command line needs a nonzero cma allocation. Based on another forum post I'm using cma=300M (unit of megabytes is required). Different people recommend different values. I suspect without proof that this is an upper bound; the driver is known to expand and contract video RAM dynamically. While other distros use /boot/cmdline, SuSE uses Grub (yay) which obeys /boot/grub2/grub.cfg which is overwritten on each update with material from /etc/default/grub. For this driver gpu_mem is irrelevant and can be left at the default (32 on SuSE, 16 on Gentoo, in megabytes).

5. Reboot, to get the changed dtoverlay=vc4-fkms-v3d and/or cma=300M.

I installed glmark2 from the SuSE repo and it got an overall score of 74, which looks like the average frames per sec of the 33 sub-tests. Comparing the overall score on different graphics platforms:

  • 17 fps for a RPi 3B with software rendering.
  • 74 fps for a RPi 3B with the GPU enabled, 4.4x faster.
  • 1831 fps for an Intel Core i5-5200U @2.2GHz with Intel HD Graphics 5500.
  • And a real gaming GPU would be faster than that.

So you won't be playing modern video games, but this is very promising for my goal of video playback. The next step is to purchase the codec licenses and install Kodi. Thank you to all who helped out on this issue and special credit to sdoconnell.

sdoconnell solved the problem! He has what he describes as a stuipdly simple solution, which he found in section 1.2.5 of the SLES documentation for Raspberry Pi. Jimc's paraphrase and extension of his solution:
  • Edit /etc/X11/xorg.conf.d/20-kms.conf and hide (comment out) 'Option "AccelMethod" "none"' to de-suppress direct rendering. SuSE turns it off by default because the vc4.ko driver by Eric Anholt is "experimental". An issue is described below, and as of 2018-09-xx to present (2018-12-xx), GPU acceleration with this problem really would not be acceptable in the SLES context. [Update: comments from a SuSE distro manager indicate that since Mesa-dri-vc4 is also not installed by default, they may or may not be going to get rid of 20-kms.conf.]
  • You also need to install package Mesa-dri-vc4 which provides the direct rendering module for the X-Server. It also is kept off the SLES installation and has to be installed explicitly by the user.
  • In extraconfig.txt you need dtoverlay=vc4-kms-v3d . Other forum posts suggest that dtoverlay=vc4-fkms-v3d ("fake" KMS) works better for streaming video and that's what jimc is using.
  • Comments on Gentoo say that the accelerated vc4 driver should not have a big gpu_mem allocation; they give gpu_mem=16 (no unit, megabytes is implicit). SuSE default is 32. This is in config.txt.
  • On SuSE, put local hacks in extraconfig.txt because config.txt gets altered in updates. It includes extraconfig.txt at the end.
  • The kernel command line needs cma=256M. The unit (megabytes) is required. This lets the GPU acquire memory dynamically, and jimc suspects without proof that this is an upper bound. Various amounts are seen in different forum posts. 256M is what Gentoo uses, and 300M is from a forum post that appears fairly authoritative to jimc. On SuSE the kernel command line is provided by Grub and the origin, editable by the sysadmin, is /etc/default/grub, which gets propagated to /boot/grub2/grub.cfg which you can tweak for experiments but which gets rebuilt in updates. Other distros get the kernel command line from /boot/cmdline.txt .
  • Look for CmaTotal and CmaFree at the end of /proc/meminfo. The default (on Gentoo without dtoverlay=vc4-kms-v3d) appears to be cma=8M. Limited experience suggests that dtoverlay=vc4-fkms-v3d sets a default of cma=256M, so you don't really need to set it explicitly on the kernel command line. In Gentoo. But in OpenSuSE if you leave it off you get zero CmaTotal and no GPU acceleration.