|Summary:||graphics/mesa-dri: enable NEON and AltiVec|
|Product:||Ports & Packages||Reporter:||Jan Beich <jbeich>|
|Component:||Individual Port(s)||Assignee:||freebsd-x11 (Nobody) <x11>|
|Status:||Closed Overcome By Events|
|Severity:||Affects Only Me||CC:||freebsd-arm, greg, linimon, manu, pete, pkubaj, x11, zeising|
|Bug Depends on:||227685|
Description Jan Beich 2017-10-14 20:34:42 UTC
Created attachment 187176 [details] v0 libvc4_neon_la is built on armv6 and armv7 but not actually used due to lack of runtime detection. powerpc* can avoid relying on SIGILL by using hw.altivec, similar to OS X. Build tested on 11.1 armv6/aarch64, 12.0 armv6/aarch64.
Comment 1 Greg V 2017-10-14 20:37:01 UTC
Is VC4 usable on FreeBSD somehow? I don't see the vc4 KMS module anywhere…
Comment 3 Jan Beich 2017-10-14 20:53:33 UTC
> Is VC4 usable on FreeBSD somehow? I guess, not yet. Bug 214580 enabled it to be future-proof. ;)
Comment 4 Niclas Zeising 2017-12-17 13:20:37 UTC
Is this patch valid for mesa 17.3? I just updated our mesa ports to that version. I want to let the mesa update simmer for a little while, before I commit this as well. Thanks!
Comment 5 Jan Beich 2017-12-18 03:55:09 UTC
(In reply to Niclas Zeising from comment #4) > Is this patch valid for mesa 17.3? Should be. src/gallium/auxiliary/util/u_cpu_detect.c didn't change since Mesa 17.2.3. NEON detection here maybe incorrect style-wise but I can't agree with arm@ folks about non-sysctl API. https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111483.html
Comment 6 Niclas Zeising 2018-05-20 10:03:31 UTC
Added this to the branch tracking mesa 18.1.0. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227685
Comment 7 Jan Beich 2018-12-07 17:22:06 UTC
Comment on attachment 187176 [details] v0 On FreeBSD NEON and AltiVec can be detected via elf_aux_info(3) which is more simple/efficient. Unfortunately, on /stable/11 the old sysctl code have to be used.
Comment 8 pete 2019-09-16 02:04:47 UTC
Is this PR still valid, or are we still waiting to land these changes to the mesa port/pkg?
Comment 9 Jan Beich 2019-09-16 13:56:23 UTC
I've submitted upstream an improved version. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1993
Comment 10 Jan Beich 2019-09-16 14:38:24 UTC
Created attachment 207539 [details] v1 - Don't bother detecting NEON on FreeBSD 11 - Switch to hw.cpu_features on powerpc* for VSX
Comment 11 Jan Beich 2019-09-16 14:47:02 UTC
Piotr, can you check build on powerpc64? If possible also run glxgears using gallium driver (e.g., llvmpipe).
Comment 12 Piotr Kubaj 2019-09-16 20:11:39 UTC
(In reply to Jan Beich from comment #11) Just tested it with llvmpipe without your patch and with it. On both configurations, glxgears segfaults. X11 may be a little faster with this patch, but this is only subjective. Note that in order to start X11, acceleration needs to be disabled by putting: Option "Accel" "off" This disables 3D acceleration, otherwise Xorg doesn't start at all. My GPU is HD 7790 and I use radeonkms from drm-current-kmod (amdgpu doesn't work on ppc64).
Comment 13 Emmanuel Vadot 2020-07-26 21:17:10 UTC
Is this still relevant ?
Comment 14 Jan Beich 2020-07-27 13:21:51 UTC
Yep. To pick up upstream fix you need Mesa >= 19.3.0. No clue whether pkubaj@ managed to fix 3D acceleration with either mesa-dri or mesa-devel.
Comment 15 Piotr Kubaj 2020-07-27 19:27:37 UTC
(In reply to Jan Beich from comment #14) I didn't get it to work. It fails because of broken tests from drm-kmod, which disable acceleration. To make it work, kernel needs to be fixed first, only then Mesa will work. There is talk on #powerpc64 that mmacy@ got it to work about a year ago, using his fork of FreeBSD (POWER9BSD), on older Radeon GPU. I also use POWER9 (but on vanilla FreeBSD) and can report that it doesn't work currently. jhibbits said he got it to work using his Amiga X5000, but it uses a very different chip. It uses NXP's embedded ppc64 chips (very nonstandard and seldom used), while POWER9 is the mainstream one (designed by IBM). NXP chips use other code in FreeBSD's kernel, so this may be why it worked. Nevertheless, NXP chips don't have AltiVec support so this patch won't help it.