Bug 223014 - graphics/mesa-dri: enable NEON and AltiVec
Summary: graphics/mesa-dri: enable NEON and AltiVec
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL:
Keywords: patch, patch-ready
Depends on: 227685
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-14 20:34 UTC by Jan Beich
Modified: 2021-05-01 09:05 UTC (History)
8 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
v0 (2.96 KB, patch)
2017-10-14 20:34 UTC, Jan Beich
no flags Details | Diff
standalone check (876 bytes, text/plain)
2017-10-14 20:48 UTC, Jan Beich
no flags Details
v1 (4.12 KB, patch)
2019-09-16 14:38 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer freebsd_triage 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 Val Packett 2017-10-14 20:37:01 UTC
Is VC4 usable on FreeBSD somehow? I don't see the vc4 KMS module anywhere…
Comment 2 Jan Beich freebsd_committer freebsd_triage 2017-10-14 20:48:42 UTC
Created attachment 187177 [details]
standalone check
Comment 3 Jan Beich freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 2020-07-26 21:17:10 UTC
Is this still relevant ?
Comment 14 Jan Beich freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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.
Comment 16 Jan Beich freebsd_committer freebsd_triage 2021-05-01 09:05:12 UTC
Obsolete after ports r552109.